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I.  INTRODUCTION 


A.  THE  PROBLEM 

In  December  of  2008,  the  Intelligence  Advanced  Research  Projects  Activity 
(IARPA)  released  a  Broad  Agency  Announcement  (BAA)  soliciting  proposals  for  the 
Social-Cultural  Content  in  Language  (SCIL)  Program.  The  intent  behind  the  SCIL 
program  is  to  investigate  methodologies,  designs,  and  technologies  that  can  contribute  in 
the  understanding  of  the  social  goals  of  persons  or  groups  of  people  by  demonstrating  a 
relationship  between  these  goals  and  their  particular  language  use  (IARPA,  2008).  By 
language  use,  we  mean  their  “manner  of  speaking”  as  opposed  to  the  language  itself 
(e.g.,  Spanish,  French).  Anyone  contributing  to  SCIL  would  be  required  to  use  Natural 
Language  Processing  techniques  to  provide  information  to  Intelligence  analysts  so  that 
they  could  advise  high-level  decision  makers.  Insight  into  the  social  dynamics  of  a  group 
would  allow  analysts  to  better  understand  the  strengths  and  weaknesses  of  a  group,  help 
identify  the  group’s  goals  and  motivation,  and  to  reduce  Anglo-centric  assumptions  about 
their  behavior  (IARPA,  2008). 

At  a  later  date,  the  University  of  Maryland  (UMD)  responded  to  IARPA’ s 
solicitation  with  a  plan  for  research  in  identifying  social  goals  pertaining  to  persuasion. 
UMD  subsequently  subcontracted  University  of  California  at  Santa  Cruz  and  the  Naval 
Postgraduate  School  (NPS)  to  work  on  the  project.  Each  institution  involved  will  serve  as 
a  performer  team  that  will  interact  and  contribute  to  the  program  via  an  aggregate  system 
based  on  a  service-oriented  architecture  (SOA).  The  information  generated  by  each 
performer  team  will  be  stored  into  a  core  knowledge  repository  for  analysts  to  examine 
for  future  events. 

The  issue  that  needs  to  be  addressed  involves  the  design  and  development  of  an 

automated  system  that  the  Naval  Postgraduate  School  (NPS)  performer  team  will  employ. 

The  design  of  a  system  will  describe  how  the  software  is  to  be  constructed  and  is  based 

on  the  requirements  set  forth  by  the  users,  in  this  case  the  stakeholders  of  the  SCIL 

program.  It  is  critical  that  a  careful  examination  of  these  requirements  be  conducted  and 
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validated  by  a  UMD  representative  to  subsequently  provide  our  performer  team  with  an 
effective  automated  system  to  execute  their  component  in  this  program.  The  system  to  be 
developed  must  be  capable  of  performing  the  following: 

•  Allow  for  local  access  for  the  collection,  storage,  and  modification  of  the 
data  to  be  forwarded. 

•  Allow  for  remote  access  to  the  data. 

•  Allow  for  the  transfer  of  data  to  the  external  knowledge  repository  over 
the  Internet. 

B.  THE  SOLUTION 

In  order  to  address  these  system  requirements,  our  research  focuses  on  answering 
the  following  three  questions: 

1 .  What  are  the  requirements  for  system  to  be  implemented  by  the  NPS 
performer  team? 

2.  What  is  the  appropriate  design  of  a  modular  framework  to  effectively 
manage  the  natural  language  assertions  in  a  knowledge  base  repository 
and  the  sharing  of  the  knowledge  via  the  World  Wide  Web? 

3.  What  is  the  appropriate  Web-service  design  to  allow  for  multiple  users  to 
update  the  knowledge  base  repository  of  natural  language  assertions  from 
multiple  sites? 

In  this  thesis,  we  addressed  the  first  question  by  generating  a  software 
requirements  specification  that  makes  use  of  various  use  cases  that  reinforce  our 
understanding  of  the  system  functionality.  The  specification  was  validated  by  a  UMD 
stakeholder.  After  a  careful  review  of  the  system  requirements,  we  used  an  object- 
oriented  analysis  and  design  approach  to  address  question  number  two.  We  developed  a 
preliminary  design  of  the  system  as  a  whole  using  various  Unified  Modeling  Language 
(UML)  notations.  We  also  analyzed  and  developed  a  database  schema  required  for  the 
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local  storage.  Lastly,  we  implemented  a  prototype  system  using  a  Web  Service 
Description  Language  file  (WSDL)  and  an  Extensive  Markup  Language  Schema 
Definition  (XSD). 

C.  ORGANIZATION 

•  Chapter  II — Background  information  on  the  concepts  behind  the  SCIL 
program,  the  Assertion  Data,  SOA,  and  Web  Services. 

•  Chapter  III — Requirements  specification. 

•  Chapter  IV — System  design. 

•  Chapter  V — Case  study  using  a  prototype  of  the  performer  team  system. 

•  Chapter  VI — Summary  of  the  thesis  and  recommendations  for  future  work. 
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II.  BACKGROUND 


A.  SOCIAL  CONTENT  IN  LANGUAGE 

1.  Introduction 

As  mentioned  in  the  Introduction,  the  intent  behind  the  SCIL  program  is  to 
employ  appropriate  theory  and  to  develop  practical  technology  in  order  to  understand  the 
social  goals  of  groups  of  interest.  IARPA  identifies  three  dimensions  of  the  Program  to 
be  of  utmost  importance:  the  social  features  and  activities  of  the  groups;  the  linguistic 
features  that  serve  as  evidence  of  social  goals;  and  the  social  science  theories  that  help 
define  the  social  features  (IARPA,  2008).  The  central  medium  of  analysis  is  the  human 
language  and  how  it  serves  as  evidence  of  social  activity. 

The  following  three  domains  of  knowledge  are  listed  in  the  BAA  as  some 
examples  in  which  any  organization  submitting  a  proposal  can  research: 

Social  Constructs  and  Activities  of  the  Group  /  Members 

•  Goals,  such  as  power,  solidarity,  group  supremacy,  religious  supremacy, 
actions,  manipulation  strategies  (e.g.,  persuasion,  coercion,  threats, 
intimidation,  oppression,  abuse,  and  exhortation),  and  recruitment 

Linguistic  Features  and  Their  Form,  Meaning  and  Strength 

•  Sacred  language 

•  Conversational  patterns  (e.g.,  turn-taking;  conversational  cues  and 

markers) 

Social  and  Cultural  Themes  and  Institutions 

•  Coercion 

•  Recruitment 

•  Loyalties  (e.g.,  family,  government,  land,  religion) 
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The  UMD  team  will  analyze  persuasion  attempts  to  contribute  to  the  overall 
program.  More  specifically,  the  UMD  performer  teams  will  seek  to  provide  information 
to  the  analysts  by  using  a  multidisciplinary  approach  to  analyze  the  language  obtained 
over  an  online  textual-based  communication  system.  Miller  defined  persuasion  as  “any 
message  that  is  intended  to  shape,  reinforce,  or  change  the  responses  of  another,  or 
others”  (Miller,  1980).  Since  the  Internet  has  quickly  developed  into  a  primary  tool  of 
communication,  it  has  since  served  as  an  ideal  means  for  individuals  or  groups  of 
individuals  affiliated  with  terrorist  organizations  to  express  their  beliefs  and  to  initiate 
persuasive  dialog  with  the  intent  to  either  convince  others  to  take  some  kind  of  action  or 
to  accept  some  proposition  or  belief.  There  are  many  services  and  massive  multi-person 
online  environments  that  facilitate  online  communication  (e.g.,  Facebook,  MySpace, 
Twitter,  World  of  Warcraft),  providing  a  medium  over  which  to  influence  and  persuade 
individuals  in  such  a  manner  that  would  negatively  affect  our  national  security. 

A  key  supporting  idea  in  theories  of  persuasion  deals  with  research  in  compliance 
gaining.  Compliance  gaining  involves  a  situation  in  which  one  person  seeks  to  convince 
another  person  to  do  something  for  him/her.  Marwell  and  Schmitt  identified  16 
compliance-gaining  strategies.  Their  paper  on  this  subject  is  seminal  because  the  majority 
of  research  up  to  that  point  was  concentrated  on  why  people  complied  with  persuasion, 
instead  of  how  they  went  about  complying  (Marwell  &  Schmitt,  1967).  Another  key 
aspect  of  persuasion  concerns  framing  effects,  which  are  different  from  compliance 
gaining  in  that  they  are  related  to  the  way  in  which  language  is  used  in  persuasion  as 
opposed  to  the  actual  decision  process  used  in  persuasive  arguments.  Framing  effects 
focus  on  the  intentional  linguistic  selection  a  person  makes  in  order  to  solicit  a  certain 
response  or  choice. 

2.  SCIL  Architecture 

For  UMD  to  accomplish  their  work  in  the  analysis  of  persuasion,  they  require  a 
multidisciplinary  approach,  which  includes  disciplines  in  linguistics,  natural  language 
processing,  and  communications  working  together  in  order  to  form  an  assertion  based  on 
raw  data.  The  raw  data  will  be  communication  text  found  online  from  various  social 
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forums.  In  the  long  run,  the  raw  data  will  be  processed  at  the  lowest  level  into  an 
automated  system  that  performs  the  natural  language  processing  using  artificial 
intelligence  to  generate  the  assertions  and  subsequently  forward  the  assertions  to  the 
knowledge  base.  For  UMD,  the  assertions  will  deal  with  persuasion  events.  Figure  1 
depicts  the  SCIL  program  architecture  as  intended,  which  demonstrates  UMD  and  other 
notional  performer  teams.  Intelligence  analysts  will  execute  queries  to  the  knowledge 
base  for  information  about  certain  groups  of  interest  without  having  to  go  through  the  raw 
data.  With  the  information  at  hand  they,  in  turn,  would  advise  higher  level  decision 
makers. 


Q 
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Knowledge  Base  Repository 


Decision 

Maker 


Automated 
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Figure  1.  SCIL  architecture 


Currently,  the  UMD  team  is  in  the  prescheduled  Base  Period,  which  consists  of 
ongoing  discussions  about  the  content  of  an  assertion,  the  definitions  of  language  use, 
and  performing  system  prototype  testing.  During  this  testing  period,  the  system  that  we 
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will  design  will  allow  for  local  UMD  researchers  to  manually  store,  manage,  and  forward 
sample  or  real  assertions  into  the  repository.  The  next  sub-section  describes  the  current 
agreed  upon  contents  of  an  assertion. 

3.  Assertions 

Assertions  about  groups  of  interest  are  what  the  analysts  will  query  from  the 
knowledge  base.  An  assertion  is  defined  as  a  declaration  about  something  with  or  without 
facts.  One  can  assert  that  the  sky  is  green,  or  even  that  computers  can  talk,  but  without 
any  evidence  or  support  those  assertions  are  meaningless.  For  our  purposes,  we  will 
further  define  an  assertion  to  be  made  up  of  the  following  three  elements: 

a.  Claim 

A  claim  is  what  the  assertion  is  about.  It  contains  a  proposition  about 
social  phenomena  in  conjunction  with  a  qualifier  that  reflects  inherent  uncertainty.  The 
claim  is  based  on  and  substantiated  by  language  use.  For  example:  “Phillip  is  a  well- 
established  leader  of  the  group.” 

b.  Evidence 

The  evidence  serves  as  the  basis  from  which  the  claim  is  derived. 
Evidence  is  composed  of  sets  of  statements  about  social-linguistic  features  and/or  social- 
cultural  phenomena  exhibited  by  the  core  data.  For  example:  “90%  of  the  topic 
discussions  are  initiated  by  John”  or  “Phillip  is  often  referred  to  as  sir.” 

c.  Support 

Support  is  the  rationale  for  asserting  the  claim  based  on  the  evidence. 
Support  is  an  explanation,  contextualization,  and  framing  of  the  claim  via  one  or  more 
context  statements.  For  example:  “People  who  initiate  discussions  are  typically  leaders,” 
or  “Men  that  are  referred  to  as  ‘sir’  are  well  respected  in  their  culture.” 

While  we  do  expect  that  the  definitions  and  concepts  behind  the  generated 
assertions  to  evolve,  our  proposed  system,  along  with  the  system  tasked  to  perfonn  the 
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natural  language  processing,  will  serve  as  a  component  deployed  in  a  service-oriented 
architecture  (SOA).  The  SOA  architecture  will  utilize  Web  services  communicating 
between  UMD  teams  and  the  SCIL  program  repository.  Section  B  describes  the 
background  of  SOA  and  section  C  will  provide  information  on  Web  services. 

B.  SERVICE-ORIENTED  ARCHITECTURE 

1.  SOA  Introduction 

The  purpose  behind  SOA  is  to  allow  for  an  enterprise  to  efficiently  build 
applications  that  provide  a  service  or  processes  to  users  while  overcoming  distributed 
computing  challenges  (Papazoglou  &  van  den  Heuvel,  2007).  The  impetus  behind  SOA 
has  been  the  limited  and  complex  nature  of  an  organization’s  legacy  IT  architecture  and 
its  inability  to  implement  solutions  in  support  evolving  business  goals.  More  so,  it  is  the 
lack  of  integration  between  an  organization’s  internal  IT  systems  and  their  business 
processes,  business  partners,  and  customers  that  is  the  driving  force  for  change  from  the 
current  system  architecture  to  one  that  is  service-oriented  (Marks  &  Bell,  2006). 

SOA  is  a  term  that  represents  a  model  or  a  design  in  which  automation  logic, 
which  seeks  to  provide  a  solution  to  a  given  concern,  is  decomposed  into  smaller,  self- 
sufficient,  and  distinct  units  of  logic  each  of  which  contribute  to  the  completion  of  the 
overall  function  (Erl,  2005).  These  decomposed  units  of  logic,  known  as  services,  can 
range  in  size  and  scope.  SOA,  in  and  of  itself,  is  not  a  technology.  The  key  behind  the 
SOA  concept  is  that  the  services  must  be  self  sufficient.  By  avoiding  inter-dependency, 
each  individual  unit  can  evolve  on  its  own  (Erl,  2005).  The  basic  method  in  which  an 
SOA  looks  to  provide  benefit  is  through  the  separation  of  concerns,  decomposition  if  you 
will,  to  allow  for  smaller  entities  to  complete  their  respective  functions  in  order  solve  the 
overall  concern. 

The  theory  behind  the  separation  of  concerns,  which  Dijkstra  references  in  his 
manuscript  EWD  447:  On  the  role  of  scientific  thought,  claims  that  there  are  benefits  in 
decomposing  a  large  problem  into  a  set  of  smaller  individual  concerns  where  each 
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individual  concern  is  addressed  by  a  unit  of  logic  (Dijkstra,  1982,  pp. 60-66).  Object- 
oriented  programming,  as  an  example,  implements  this  concept  with  its  use  of  objects, 
classes  and  components. 

Ideally,  the  services  in  a  SOA  should  not  only  be  aware  of  other  services  but  be 
able  to  communicate  with  them.  The  services  utilize  what  is  called  a  service  description 
to  identify,  locate,  and  manage  the  communication  between  services.  The  communication 
between  the  services  takes  place  via  a  framework  called  messaging.  Each  message  while 
underway  from  service  to  service  is  also  self-sufficient  and  not  dependent  on  anything 
but  itself  (Erl,  2005). 


So  far,  what  has  been  described  is  the  basic  architecture  of  what  SOA  is  about. 
Figure  2  provides  a  visual  representation  of  the  basic  architecture  thus  far. 
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Figure  2.  SOA  architecture 


Erl  provides  us  with  a  simple  analogy  of  the  concept  behind  SOA,  comparing  it  to 
a  business  community.  Every  city  has  some  business  community  that  consists  of  entities 
ranging  in  size  from  a  Wal-Mart  to  a  local  mom  and  pop  store.  These  businesses  provide 
services  to  us  as  consumers,  similar  to  how  the  units  of  logic  (services)  from  a  system 
perform  a  function  and,  if  you  take  the  business  community  as  a  whole,  it  seeks  to  solve  a 
particular  demand,  much  like  how  the  automation  logic  provides  a  solution  for  an  overall 
concern.  The  services  still  have  certain  established  regulations  that  must  be  followed.  In 
SOA,  these  regulations  are  the  principles  that  drive  service-orientation  (Erl,  2005). 
Continuing  with  the  business  community  analogy,  the  analogous  regulations  in  place 
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could  consist  of  a  common  currency  that  must  be  used  for  a  transaction  or  even  a 
common  language  that  must  be  spoken.  The  services  follow  a  set  of  common  service- 
orientation  principles  through  a  process. 

2.  Principles  of  SOA 

The  following  are  commonly  accepted  principles  of  service-orientation  as 
described  by  Thomas  Erl: 

a.  Services  Are  Reusable 

Reusability  benefits  by  reducing  the  need  for  future  development  efforts. 
An  analogy  would  be  similar  to  how  the  Department  of  Motor  Vehicles  (DMV)  services 
all  requestors  for  a  driver’s  license,  but  an  even  more  reusable  service  would  be  a  DMV 
that  distributed  licenses  to  users  of  all  types  of  vehicles  (ground,  rail,  aviation,  boat,  etc.). 

b.  Services  Share  a  Formal  Contract 

Similar  in  concept  to  how  a  consumer  would  need  to  fill  out  an  application 
for  the  vehicle  license  mentioned  above,  the  contract  defines  the  service,  the 
operations/activities,  and  the  messaging  that  are  required  to  consume  the  service. 

c.  Services  Are  Loosely  Coupled 

Loose  coupling  facilitates  agility.  The  factors  that  influence  change  in  an 
IT  environment  are  external,  and  so  it  is  important  that  the  underlying  logic  behind  the 
individual  services  be  independent.  After  we  have  waited  in  line,  filled  out  our 
application,  and  taken  the  test  at  the  DMV,  the  responsibility  is  on  the  DMV  to  process 
and  provide  us  with  the  license. 

d.  Services  Abstract  Away  Underlying  Logic 

The  details  (underlying  logic)  that  make  the  service  work  are  hidden,  and 
of  no  concern  to  the  user  as  long  as  the  service  works.  Not  many  people  know  or  care 
exactly  what  the  DMV  does  in  order  to  process  their  request  for  a  license. 
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e.  Services  Are  Composable 

Composable  means  that  services  can  have  subservices.  A  service-oriented 
process  is  one  that  has  a  parent  process  in  which  it  calls  its  underlying  services  to  perform 
a  subfunction.  This  principle  reinforces  reusability.  The  local  law  enforcement  agency 
would  require  the  use  of  the  new  DMV  to  license  their  drivers  as  well. 

f  Services  Are  Autonomous 

Autonomy  allows  for  self-governance  of  all  its  processing,  which 
subsequently  allows  for  a  service  that  is  free  from  any  dependencies  that  would  restrain 
its  deployment  and  evolution  (Erl,  2005).  Let  us  assume  that  the  new  DMV  requires  a 
background  check  on  people  applying  for  a  license.  The  DMV  normally  delegates  that 
task  to  another  agency,  and  is  dependent  on  their  results.  If  the  DMV  were  to  perfonn  its 
own  background  check,  this  independence  would  allow  for  the  DMV  to  evolve  its 
services  without  being  held  back  by  a  dependent  functionality. 

g.  Services  Are  Stateless 

If  a  service  is  tied  up  by  managing  information,  it  reduces  its  own  ability 
to  receive  other  requests  from  other  requestors.  A  stateless  service  promotes  reusability 
and  scalability  by  forwarding  the  message  received  and  forgetting  that  it  ever  had  the 
message,  let  alone  what  it  was  about.  A  services  state  is  dependent  on  how  well-designed 
the  indiviual  operations  are,  and  how  they  function.  The  self-sufficient  messages 
mentioned  previously  support  statelessness.  After  completing  the  processing  for  an 
applicant’s  license,  the  details  behind  the  application  are  saved  in  a  database  and  there  is 
no  reason  for  the  DMV  to  linger  on  your  request.  By  doing  so,  it  would  inhibit  the  ability 
to  service  other  applicants. 
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h.  Services  Are  Discoverable 

Discoverability  prevents  redundancy  in  service  development.  A  discovery 
mechanism  should  be  in  place  that  enables  potential  clients  who  need  your  service  to 
locate  and  consume  it.  The  DMV  information  (location,  phone  number,  etc.)  can  be 
found  in  the  yellow  pages,  the  Internet,  or  even  signage  on  the  highway,  which  is  how  we 
know  to  go  there  to  begin  with. 

3.  Benefits  of  Using  SOA 

We  have  vaguely  touched  on  the  benefits  of  using  a  SOA  for  any  particular 
organization.  Not  all  organizations  require  a  change  or,  specifically,  a  shift  in 
architecture,  but  for  those  organizations  that  are  finding  it  costly  to  make  changes  to  their 
current  IT  structure  in  response  to  a  dynamic  business  environment,  an  SOA  solution 
may  be  worth  exploring.  SOA  provides  developers  with  a  means  to  overcome  many 
distributed  enterprise  computing  challenges,  such  as  application  integration,  transaction 
management,  and  security  policy  enforcement,  while  allowing  the  concurrent  use  of 
multiple  platforms  and  protocols  and  leveraging  numerous  access  devices  and  legacy 
systems  (Alonso  et  ah,  2004). 

Depending  on  how  it  is  used,  the  benefits  of  SOA  relate  to  the  aforementioned 
principles  and  include  the  following:  the  costs  of  integrating  your  applications  will  be 
reduced,  your  returns  on  investment  will  increase  due  to  the  reusability  principle,  a 
reduced  processing  overhead  and  reduced  skill-set  requirements  are  experienced  due  to 
the  services  being  composable,  the  need  to  replace  legacy  systems  is  reduced,  which  in 
turn  saves  money,  the  use  of  a  standardized  language  like  Extensive  Markup  Language 
(XML)  reduces  the  cost  and  efforts  of  application  development,  and  the  costs  involved  in 
responding  to  changes  via  external  sources  are  also  reduced  (Erl,  2005). 
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C.  WEB  SERVICES 

A  Web  Service  (WS)  is  defined  by  the  World  Wide  Web  Consortium  (W3C)  as: 

A  software  system  designed  to  support  interoperable  machine-to-machine 
interaction  over  a  network.  It  has  an  interface  described  in  a  machine- 
processable  format  (specifically  WSDL).  Other  systems  interact  with  the 
Web  service  in  a  manner  prescribed  by  its  description  using  SOAP 
messages,  typically  conveyed  using  HTTP  with  an  XML  serialization  in 
conjunction  with  other  Web-related  standards.  (W3C,  2004) 

Basically,  a  WS  is  a  method  of  implementing  a  distributed  system,  which  allows  for 
objects  on  one  computer  to  interact  with  those  of  another  computer  over  the  Internet. 
There  are  currently  two  prominent  models  used  for  creating  Web  Services:  the 
Representational  State  Transfer  (REST)  model  and  the  SOAP-based  model. 

1.  RESTful  Web  Services 

RESTful  WS  allow  for  access  to  resources  on  a  network  referenced  via  a  Uniform 
Resource  Locator  (URL).  REST  uses  HTTP  as  the  primary  transportation  protocol  to 
support  the  execution  of  one  of  the  four  methods:  GET,  PUT,  DELETE,  and  POST. 
REST  services  have  limited  support,  in  that  REST  has  no  standardization,  few  toolkits, 
and  little  by  means  of  software  library  support.  Message  exchange  can  be  performed  in 
various  fonnats  (e.g.,  XML,  HTML).  Figure  3  shows  an  example  request  and  associated 
response  for  a  RESTful  service. 


Request  Response 


GET  StockPncelBh  1  HTTP  1  1 
Host:  cxamplc.org 
Accept:  text  xml 
Accept-Charset  utf-8 

Figure  3.  REST  Web  service  request  /  response  (From  Spies,  2008) 
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HTTP  1.1  200  OK 

Content-Type:  text  xml,  charset=utf-8 
Content-Length  aim 

<?xml  version—'  l  .0”?> 
s  Quote  xmlns:s="http  example  org  stock - 
service"  > 

<s:Tickei  Symbol  IBM  s  Ticket  Symbol 
-  s  StockPricc  45  2?  s:StockPnce> 
sQuote 


2. 


SOAP-Based  Web  Services 


SOAP  is  the  accepted  standard  method  of  communication  between  computers 
over  the  Internet  that  specifically  uses  XML  to  represent  the  information  passed.  SOAP  is 
supported  with  toolkits  and  various  software  libraries.  The  earliest  version  of  SOAP, 
version  1.1,  was  adopted  by  the  W3C  after  its  submittal  in  May  of  2000.  SOAP,  which 
once  stood  for  Simple  Object  Access  Protocol,  is  currently  in  version  1 .2  and  is  based  on 
messages  taking  the  form  of  documents.  The  encoding  behind  the  request  and  response 
operations  of  SOAP  WS  is  in  XML  format  and  the  network  transportation  protocol  can 
be  by  any  means  (e.g.,  IBM  MQSeries,  MSMQ,  or  SMTP)  but  the  most  common 
protocol  is  HTTP.  For  this  research,  we  will  focus  on  SOAP-based  Web  Services.  Figure 
4  shows  an  example  request  and  associated  response  for  a  SOAP-based  service. 


Request 

Response 

GET/StockPrice  HTTP/1. 1 

HTTP/1 . 1  200  OK 

Host:  example.org 

C  ont  ent  -Ty p  e :  appli  c  ati  on/ s  o  ap+xml ; 

Content-Type:  application/soap+xml;  charset=utf-8 

charset=utf-8 

Content -Length:  nnn 

Content -Length:  nnn 

<?xml  version— 1 1 . 0"  ?> 

<?xml  version— '  1 . 0" ?> 

<env:Envelope  xmlns:env  ="http:  //www.w3.org/  2003/05/ 

<env:Envelope  xmlns:  env— 'http: //www. w3.org/ 2003 /05 /soap-envelope  " 

soap -envelope" 

xmlns:  s="  http:  //www.  example,  org/stock-service "  > 

xmln  s :  s— 1  http :  //www.  ex  ampl  e .  or g/  st  o  ck-s  erv  i  c  e "  > 

<env:Body> 

<env:Body> 

<s:GetStockQuoteResponse> 

<s:  GetStockQuote> 

<s:StockPnce>45.25</s:StockPnce> 

<s:TickerSymbol>IBM</  s:  TickerSymbol> 

</s:GetStockQuoteResponse> 

</s:  GetStockQuote> 

</env:Body> 

</env:Body> 

</env:Envelope> 

</env:Envelope> 

Figure  4.  SOAP  Web  service  request  /  response  (From  Spies,  2008) 


3.  Web  Service  Components 

As  mentioned  previously,  SOA  consists  of  units  of  logic  known  as  services  that 
require  a  means  either  to  locate  other  services  or  to  advertise  services.  SOA  also  supports 
a  means  of  communication  that  would  enable  interaction  between  services.  In  this 
section,  we  will  elaborate  more  on  each  component  that  makes  up  a  WS. 
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a.  Services 

A  WS  can  be  classified  as  being  temporary  or  permanent,  depending  on 
the  function  that  it  assumes  during  runtime  or  its  application  logic.  The  basic  service 
roles  a  service  plays  are  that  of  a  provider,  intermediary,  and  a  requestor  (Erl,  2005).  In 
the  requestor  role,  the  service  will  initiate  the  transmission  of  a  message  requesting  a 
particular  service  of  which  the  provider  was  designed  to  execute.  The  provider  will 
execute  the  request  and  respond  to  the  requestor.  As  an  intermediary,  the  service  will 
process  a  message,  perfonning  its  own  functionality,  and  forward  the  request  to  its 
service  provider.  Some  functions  an  intermediary  service  can  perform  are  authentication 
services,  auditing  services,  and  management  services  (Irani,  2010). 

Services  based  on  the  nature  of  the  application  logic  in  which  the  service 
is  intended  to  perfonn  are  classified  as  service  models.  For  example,  a  service  can  be  of  a 
Business  type  (e.g.,  Accounts  Payable  Service)  that  executes  one  of  many  operations 
required  by  an  organization,  a  Utility  type  (e.g.,  Internal  Policy  Service)  that  is 
completely  reusable  and  non-application  specific,  or  a  Controller  type  that  would  be 
responsible  for  the  coordinated  functionality  of  all  of  the  services  within  an  organization 
(Erl,  2005). 


b.  Description 

In  order  for  services  to  interact,  they  first  need  to  be  aware  of  each  other. 
Specifically,  a  provider  needs  a  formal  description  of  its  services.  The  description  acts  as 
a  contract  with  clients  who  request  the  provider’s  service.  A  W3C  standardized  WSDL 
document  serves  this  purpose.  WSDL  is  defined  as: 

An  XML  format  for  describing  network  services  as  a  set  of  endpoints 
operating  on  messages  containing  either  document-oriented  or  procedure- 
oriented  information.  The  operations  and  messages  are  described 
abstractly,  and  then  bound  to  a  concrete  network  protocol  and  message 
format  to  define  an  endpoint.  (W3C,  2001) 
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The  WSDL  file  is  also  written  in  XML  and  describes  the  data  that  will  be 
passed  and  the  method  that  passes  it  regardless  of  the  programming  language  used.  This 
means  that  a  service  written  in  Python  can  be  consumed  by  client  created  in  Java. 

Although  a  WSDL  is  subdivided  into  several  sections,  it  is  generally 
composed  of  two  key  components:  an  abstract  interface  description  (i.e.,  operations, 
operation  parameters,  and  abstract  data  types)  and  a  concrete  implementation  description 
(i.e.,  a  network  address,  a  protocol,  and  concrete  data  structures;  Zimmermann, 
Tomlinson,  &  Peuser,  2003),  the  latter  of  which  provides  the  means  to  actually  invoke 
the  service.  Let  us  briefly  look  at  the  main  elements  found  in  a  standard  .wsdl  file.  The 
text  and  sub-tags  within  a  .wsdl  file  are  encapsulated  inside  of  a  <definitions>  element 
and  from  top  to  bottom  the  five  main  elements  within  are:  <types>,  <messages>, 
<portTypes>,  <binding>,  and  the  <service>. 

•  <types> — This  element  includes  the  abstract  information  set  using  an 
XML  Schema  that  defines  the  data  types  used  in  the  communication 
process  between  the  service  provider  and  the  requestor.  If  there  are  an 
excessive  number  of  data  types  described,  the  schema  can  be  imported 
into  this  section  as  a  separate  document. 

•  <messages> — The  message  element  defines  the  abstract  content  of  the 
messages  to  be  communicated.  The  content  includes  the  name  of  the 
message  part  (what  the  message  is  called),  the  element  attribute  that  refers 
to  the  XML  schema  (what  the  message  is),  and  the  type  (the  type  of  data  it 
holds). 

•  <portTypes> — The  port  type  element  identifies  and  describes  a  specific 
service  interface.  It  is  a  named-set  of  abstract  operations  and  their  abstract 
messages  that  come  in  two  varieties,  input  and  output.  The  operations  are 
made  up  of  the  messages  described  in  the  messages  element. 

•  <binding> — The  purpose  of  the  binding  element  is  to  connect  the  abstract 
port  type  description  to  a  concrete  service  implementation.  The  protocol 
details  to  send  the  messages  are  defined  here. 
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•  <service> — The  service  element,  which  is  also  known  as  the  endpoint, 

specifies  where  and  how  to  send  the  information.  The  service  element 
works  with  the  binding  element  by  connecting  a  port  type  to  a  particular 
port  defined  within  the  service  element. 

Figures  5  and  6  are  excerpts  from  two  WSDL  documents  entitled 
stepGovServices_12.wsdl  and  stepPortTypes_12.wsdl  (Tong,  2009).  These  files  are 
referenced  again  in  Chapter  IV. 


\ Ml. Schema  is  imported. 


Name  of  X  MI.  Schema 


<wsdl  detinitions> 

<wsdttypes> 

<xs  schema> 

<xs  import  namespace=”http  r/www  larpa  gov/SCILifSTEP_Schema”  schemat,ocation="stepSchema_1 1  xsd7> 
</xs  schema> 

</wsdl  types> 

<wsdl  message  name='KbUpdateRequest'> 

<wsdl  part  name=''updateRequest"  eiement=”step<i  KbUpdateRequestMsgPart'7> 

</wsdl  message  > 

<wsc0  message  name="KbUpdateResponse‘> 

<wsd)  part  name="updateResponse'  element="stepd  KbUpdateResponseMsgPart7> 

<Vwsdl  messages  Message 

<wsdl  message  name ='SlatusReportRequest>  elements 

:  <wsdl  part  name="statusRequest"  element='stepd  StatusReportRequestMsgPart'7> 

</wsdl  messages 

<wsdl  message  name-'StatusReportResponse"> 

<wsd)  part  name^'statusResponse"  elemen1='stepd  StatusReportResponseMsgPart7> 

<7wsdl  message  > 

<wsdl  portType  name="KbUpdatePortType''> 

<V/sdl  operation  name='KbUpdate"> 

<wsdl  inpot  message="steps  KbUpdateRequest"/> 

<wsdl  output  rr>essage="steps:KbUpdateResponse'7> 
i  </wsdl  operation  > 

</wsdl  portType> 

<wsdl  portType  name='  StatusReportPortType"> 

<wsdl  operation  name- 'StatusReport"> 

<wsdl  input  message="steps  StatusReportRequest'7> 

<wsdl  output  message="steps  StatusReportResponse7> 

|  </wsdl  operation  > 

</wsdl  portTvpe> 


Port  Types 


Figure  5.  WSDL,  abstract  interface  description 
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<ivsdl  binding  name=  KBUpdateSoap&ndmg  type- 'steps  KbU pdatePortType  >  — 

<so»p1?  bindmg  style0  "document  tran*porta1lHp  //schemas  xmlsoap  ixg/soap-htlp'/* 

^wsd!  operation  name*  KbUpdate'* 

«soap12  operation  soaoAction='kbUpdate'  soapAct<onReqi*red="tiue'  style-'document'/* 

•  rtsnl  input  > 

j  |  <soap12  body  use-'lileral'  ^ 

<-'wsdl  input  > 

CWSdl  OUtpUt  '- 

:  :  |  <soap12  body  use -'literal'  '> 
j  j  </Wsdl  outpul> 

|  <<wsdl  operation>  , 

</wsdl  binding>  __  Binding 

<y<sdi  binding  name=  StalusRepottSoapBinding"  lype=' steps  StatusReportPoitType‘>  clt'Ul 0111* 

«soap12  bmdwig  style  - '  document'  Imn* port -"http  //schemas  xmlsoap  org/soapdittp'/s 
operation  name=  "StatusReport  '* 

<soap12  operation  soacActton='statusRepoft’  soapActonRequ°red=  true'  style- document'/* 
cMsdl  input* 


<soapt2  body  use^'literaT/* 

</wsdl  input* 

<wsdl  output* 

<soap12  body  us«='literal'  ■> 
ci'wsdl  output* 
j  </wsdl  operation* 

</*sdl  binding* 

<v/sdt  seivtce  name='UMD_KbUpdate*> 

<w$ds  port  name -"KbU  pdatePortType'  bmdng-'steps  KBUpdateSoap6mding* 
<soap12  address  location -"http  //localhosl  8080/UhtOSCIL‘Uf<1D_KbUpdate'.'> 

:  </wsdl  port* 

■c/wsdlservice* 

<»*sdi  seivtce  n*m* = 'UMD  StatusReport  * 

<ws<#  port  name*"StatusReporlPortType'  bmAng*  slops  StatusReportSoapBinibng'  > 
<soap12  address  location- 'http  /Vlocalhost  80M/Uh©SCIL'VMD_StatusReport7* 

;  </wsdl  port* 
c/wsdl  sen/ice* 


Service 

dements 


de1tfwtion$> 


Figure  6.  WSDL,  concrete  implementation  description 


c.  XML  Schema  (XSD) 

An  XSD  is  a  model  document  that  defines  the  structure  of  a  separate  XML 
document.  The  XML  document  will  contain  a  reference  to  the  XSD  that  defines  its 
structure,  much  like  how  the  schema  is  imported  to  support  the  WSDL  document  in 
Figure  5.  The  schema’s  syntax  is  entirely  in  XML,  and  it  serves  to  validate  the  XML 
document’s  adherence  to  the  schema’s  structure.  An  XSD  can  contain  several  subordinate 
element  types,  similar  to  a  WSDL,  and  tends  to  be  very  complex.  However,  some  of  the 
basic  elements  that  you  will  find  in  an  XSD  are:  <elements>,  <attributes>, 
<simpleType>,  and  <complexType>;  all  of  which  serve  to  define  the  text  data  as  strings, 
integers,  dateTime,  or  data  types.  Figures  7  and  8  are  excerpts  from  an  XSD  named 
stepSchema_12.xsd  (Tong,  2009). 
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This  element  consists  of  two  main 
elemeuts Metadata  and  Payload, 


<xs  element  name='KbUpdateRequestMsgPart"> 

<xs  annotations 
<xs  complexTypes 
<xs  sequences 

<xs  element  name="Metadata's  * - - “ " 

<xs  comptexType> 

<xs:  sequences 

<xs  element  name- 'Messageld”  type="xs  stnng's 
|  <xs  annotations 
</xs  elements 

<xs  element  name=Teamld"  type="stepd  Teamld's 
I  <xs  annotations 
</xs.elements 
</xs  sequences 
!  </xs  complexTypes 
</xs  elements 

<xs  element  name- Payload's 
<xs  complexTypes 
<xs  choices 

<xs  element  name='AssertionAddBundle'  type="stepd  AssertionAddBundle7> 

<xs  element  name="AssertionReplaceBundle'  type="stepd  AssertionReplaceBundle7s 
<xs  element  name=-AssertionDeleteBundle'  type=‘stepd  AssertionDeleteBundle'Vs 
</xschoices 

Payload'.  Coiis'isls  of  an  option  of  one  of  three 
Bundles  AsseitionAdd.  A^eitioiiReplace.  and 
AsseiiionDelele  of  winch  ate  also  defined  witlrin 


Metadata:  Consists  of  a  Message  ID 
that  is  string  and  a  leant  ID  Hint  is 
defined  further  along  m  the  x**l 


</xs  complexTypes 
<Vxs  elements 
</xs  sequences 
</xs  complexTypes 
</xs  elements 


the  xsd 


Figure  7.  XSD  I 
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<x*  simpleTyp#  nam»="T#amld'> 

<xs  annotation* 

j  <xs  document  at ion>Type  that  enumerates 
</xs  annotation* 

<x*  restriction  bas*-‘xs  stnng" >  ' 

<xs  enumeramon  value- 'ALB7> 
oxs  enumeration  value1 'ASU'V* 

<xs  enumeration  value-  B8N'V> 

<xs  enumeration  v»lue=C0l7> 

<xs  enumeration  value='LCC‘/> 

<xs  enumeration  value=  SRI7> 

<xs  enumeration  value-  UMD7> 

<xs  enumeration  value=  UWA7> 

<xs  enumeration  value='G0V7> 

|  <lxs  restnction> 

</xs:simpleType> 


the  Performer  team  IDs  <;xs  documentation* 


AsserlionAdtlBuntlle  contains  a 
set  of  sub-elements  as  well 
including  Payload  which  is  also 
defined  somewhere  in  the  xsd 


Team  ID  is  restricted  to  be  one  of  the  several  types  of 

Ids  listed,  that  are  basically  strings 


<xs  complexType  name- Asseftio(\AddBun<He*> 

<xs  annotating 
<X5  sequence 

<xs  element  oame-’-'Mrtadata'^ 
j  <xs  complexType> 

<xs  &equence> 

<xs  element  rame=  AssaitionCounl'* 

<X5  simulation-* 

<xs  simpleTyp9> 

|  <xs  restriction  bese="xs  integer  > 
j  <xs  mmlnclusrd*  *akie«"1*7> 

!  </xs  resmctxm> 

<Vx*  simple  Typ«> 

<fxs  element> 

</XS  sequence  > 

</xs  c<ynplexTyp*> 

</x*  element  > 

<xs  element  nam*=’ Payload’  > 

!  <xs  complexType> 

•  <xs  MQuenco> 

<xs:  element  name=  Assertion*  tyoe-  stepd  KGAssertion’  TexOccurs=*unbotncec“> 
I  <xs  aimutatiun> 
f  </xs  element > 

</xs  sequence  > 

1  </xs  cemplexType> 

</xt  element  > 
sequence  > 

<Vxs  complexType> 


Figure  8.  XSD  II 


d.  Messaging 

The  communication  protocol  shared  between  services  is  the  standard 
HTTP  application  layer  used  by  clients  and  servers  over  the  Internet.  However,  since  the 
communication  between  services  is  message-based,  the  framework  used  should  be 
standardized,  flexible,  and  highly  extensible  (Erl,  2005).  The  SOAP  messaging 
framework  meets  these  requirements.  A  SOAP  message  contains  the  following  elements: 
<Envelope>,  <Header>,  and  <Body>. 

•  <Envelope> — The  header  is  a  mandatory  element  that  acts  as  a  container 

for  the  header  and  body  elements.  This  element  defines  itself  (an  XML 
document)  as  a  SOAP  message. 
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•  <Header> — The  header  element  is  optional  and  provides  a  means  to  pass 
any  kind  of  additional  processing  or  control  information  to  recipients  of 
the  message. 

•  <Body> — The  body  is  mandatory  in  that  it  holds  the  actual  SOAP 
message  intended  for  the  service  provider. 

Figure  9  demonstrates  a  basic  example  of  a  client  service  requesting  a 
connection  identification  number  by  sending  a  SOAP  message  containing  a  user  name 
and  password.  The  service  provider  responds  to  the  requestor  with  the  connection 
number. 


Ed*  Project 

XML 

DTD/Schema 

Schema  design 

XSL/XQoery 

Authentic  QB  Convert  View 

a 

'  «o 

M  £•& 

GB  cl 

7  cga Qja  BJEg  J 

k  1  .  <SOAP  ENV  Envelope  xrrrins  $  >AP  ENV=  http //schemas  xmlsoaporgisoap  envelope 


r  >  mins  xsi='http  //vw*w  w3  org/200 1  /XMLSchema-mstance"  xmlns  xsd='http  //www  w3  c 

2  <SOAP-£NV  Body> 

3  <m  connect  xmtns  m='um  exisf> 

4  <m  userfd>3dmin<'m  userid > 

5  <m  password>p3ssword<.m  pa$sword> 

6  ;  </mconnect> 

7  </SOAP-ENV  8ody> 

8  </SOAP-EMV  Envelope  > 

9 


»  £ 

— 

2  E 

csoapenv  Envelope  xmlns  soapen/="http  //schemas  xmlsoap  org/soap/enve 

http  //www  w3  org/200 1/XMLSchema-rnstance> 

3  4 

<soapenv  Body> 

i 

<connectResponse  xmlns="um  exist"> 

5 

<connectRetum>7135854</connectRetum> 

6 

</connectResponse> 

7 

</soapenv  Body> 

8 

9 

</soapenv  Envelope> 

Figure  9.  SOAP  message 
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D. 


SUMMARY 


This  chapter  began  with  an  overview  of  the  SCIL  program  intended  to  identify  the 
social  goals  of  a  group  of  interest  and  its  members  by  analyzing  language  features.  UMD 
has  proposed  a  research  supporting  the  program  that  involves  addressing  the  social 
phenomenon  of  persuasion.  UMD  will  conduct  a  multidisciplinary  approach  to  analyze 
the  language  and  its  use  to  detennine  if  the  intent  to  persuade  is  present.  In  order  to  make 
this  happen,  online  text  dialogue  needs  to  be  collected  and  analyzed  to  create  assertions 
identifying  persuasion  attempts.  These  assertions  must  be  processed  by  a  system  capable 
of  performing  the  following:  collect,  modify,  and  locally  store  the  data,  allow  for  remote 
access  to  the  data,  and  allow  for  the  transfer  of  data  to  the  external  knowledge  base 
repository  over  the  Internet.  We  also  covered  some  of  the  background  on  SOA  and  its 
benefits  and  we  finished  the  chapter  with  a  discussion  on  Web  Services  along  with  their 
common  protocols  (i.e.,  WSDL,  XSD,  SOAP).  In  Chapter  III,  we  will  address  the  key 
features  and  requirements  necessary  for  the  development  of  our  proposed  system. 
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III.  SYSTEM  REQUIREMENTS  SPECIFICATION  (SRS) 


A.  OVERVIEW 

A  software  requirement  is  defined  as  a  “software  capability  that  must  be  met  or 
possessed  by  a  system  or  system  component  to  satisfy  a  contract,  standard,  specification, 
or  other  formally  imposed  documentation”  (Leffingwell  &  Widrig,  2003).  The 
methodology  used  to  derive  the  following  requirements  for  our  proposed  system  were 
based  on  a  face  to  face  interview  with  a  SCIL  representative  and  an  agreed  upon  set  of 
use  cases  to  describe  the  general  system  functionality. 

1.  Purpose 

The  purpose  for  this  SRS  is  to  determine  the  functional  and  nonfunctional 
requirements  necessary  to  effectively  store,  process,  and  transfer  assertion  data  generated 
by  the  local  UMD  performer  team  in  support  of  the  SCIL  program. 

2.  System  Perspective 

This  software  is  a  new  and  self-contained  product  that  is  a  separate  component  of 
a  larger  system  design  that  includes  other  performer  clients  and  services  from  various 
learning  institutions  and  a  central  application  server  that  provides  a  WS  endpoint.  Other 
performer  systems  will  interact  with  the  application  server  in  the  same  way. 

3.  System  Features  and  Domain  Model 

The  major  features  of  this  system  include  two  Web  services:  one  that  will  display 
a  local  service  status  when  queried  by  an  external  client;  and  another  that  will  allow  for 
an  external  client  to  retrieve  assertion  data,  a  WS  client  that  will  be  capable  of  updating 
the  external  knowledge  base,  a  software  application  that  will  be  used  to  manage  the 
assertion  data  and  services,  and  a  database  used  to  store  the  data.  All  of  the 
aforementioned  features  and  interfaces  will  be  written  in  or  interact  with  the  JAVA 
programming  language. 
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Figure  10  is  a  domain  model,  which  displays  a  visual  perspective  of  the  concepts 
relative  to  the  proposed  system.  The  local  users  will  use  the  system  to  create  assertions  to 
be  stored  locally.  The  assertion  text  is  composed  of  a  claim,  evidence,  and  support  data. 
The  assertion  text  combined  with  a  local  system-generated  assertion  ID  (local  ID),  and 
IARPA’s  external  system-generated  assertion  ID  (external  ID),  and  a  date  and  time  group 
(DTG)  form  a  knowledge  base  assertion  that  is  stored  locally. 

Our  system  will  deploy  two  Web  services:  ExplanationGetWS  and 
StatusReportWS.  The  ExplanationGetWS  will  allow  for  clients  to  retrieve  assertion  data 
from  the  local  system.  Our  system  will  also  execute  one  WS  client:  KbUpdate  client. 
KbUpdate  client  will  interact  with  the  external  system’s  WS  to  transfer,  replace,  or  delete 
assertion  data.  Our  KbUpdate  client  and  ExplanationGetWS  will  have  a  status  associated 
with  them  that  will  be  returned  in  response  to  queries  to  the  StatusReportWS.  The  core 
operations  will  be  explained  in  more  detail  in  Chapter  IV.  Both  Web  services  will  be 
deployed  on  an  application  server  that  will  allow  for  their  consumption  by  the  external 
system.  The  domain  model  also  depicts  a  DataPush  client.  The  purpose  behind  the 
DataPush  client  has  not  been  agreed  on  by  the  UMD  stakeholders  at  this  time;  therefore, 
aside  from  its  place  in  the  domain  model,  this  research  will  not  include  the  DataPush 
functionality. 
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Figure  10.  Domain  model 


4.  Intended  Audience 

This  SRS  is  intended  to  be  read  by  the  local  users  and  project  managers  who 
represent  the  UMD  team  in  support  of  SCIL. 

B.  FUNCTIONAL  REQUIREMENTS 

This  section  begins  the  description  of  the  system  features  utilizing  several  use 
cases  that  serve  as  functional  requirements.  The  use  cases  are  scenario-driven,  meant  to 
provide  us  with  both  an  outside-in  view  of  the  system  functionality,  and  a  critical  tool  in 
the  analysis  process.  Figure  1 1  is  a  use-case  diagram,  which  introduces  the  system  actors 
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and  their  respective  interactions  with  the  system.  The  elements  listed  under  UMD  System 
represent  the  individual  use  cases,  and  will  be  explained  in  more  detail.  As  a  reminder, 
the  local  users  will  be  replaced  by  an  automated  system  that  creates  the  assertion  from  the 
input  of  raw  data  in  the  future. 

Following  each  use  case,  we  have  provided  a  system  sequence  diagram  (SSD).  An 
SSD  is  “a  picture  that  shows,  for  one  particular  scenario  of  a  use  case,  the  events  that 
external  actors  generate,  their  order  and  inter-system  events”  (Larman,  2005).  The  point 
behind  the  SSD  is  to  identify  the  particular  events  that  will  transpire  during  execution 
giving  us  a  clearer  picture  of  the  system  behavior. 
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1. 


Local  User  Stores  Assertion 


Table  1.  Local  user  stores  assertion 


Primary  actor 

Local  user 

Stakeholders  and 

interest 

•  Local  user  wants  to  store  the  assertion  in  to  the  local 

database. 

•  External  user  needs  the  assertion  to  be  accessible. 

Entry  conditions 

•  The  local  user  workstation  needs  to  be  operational. 

•  The  local  user  has  already  logged  in. 

•  The  local  user  can  access  the  assertion  text  via  the 

local  workstation. 

Exit  conditions 

•  The  assertion  has  been  assigned  an  external  ID. 

•  The  assertion  is  stored  within  the  local  database. 

Main  scenario 

1 .  The  system  displays  a  menu  option,  which  includes  the 

option  to  store  the  assertion. 

2.  Local  user  selects  the  option  to  store  assertion. 

3.  The  system  displays  an  interface  that  allows  for  the 

manual  entry  of  the  data  along  with  the  option  to  store 

the  assertion. 

4.  Local  user  manually  enters  the  assertion  data  into 

provided  text  fields. 

5.  The  local  user  selects  the  option  to  store. 

6.  The  system  generates  an  local  ID  for  the  assertion. 

7.  The  system  generates  the  DTG  for  this  instance. 

8.  The  system  stores  the  assertion,  respective  DTG,  and 

local  ID  into  the  local  database. 

9.  The  system  displays  the  local  ID  to  the  user  along 

with  a  message  stating  that  the  operation  is  complete. 

•  The  User  repeats  steps  2-9  until  complete 
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10.  The  local  user  logs  off  of  the  workstation. 

Extensions 

*a .  Workstation  System  failure: 

1 .  The  local  user  restarts  the  system  and  logs  in. 

2.  The  system  assumes  its  state  prior  to  step  1  in  the 

main  scenario. 

3.  The  local  user  re-attempts  the  storing  process 

4a.  Invalid  input: 

1 .  The  system  displays  an  “invalid  input  error”  message 

stating  that  the  data  entered  was  incorrect. 

2.  The  system  returns  to  the  state  at  step  3  in  the  main 

scenario. 
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Figure  12.  Store  assertion  SSD 
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2. 


Local  User  Transfers  Assertion  to  Knowledge  Base 


Table  2.  Local  user  transfers  assertion  to  knowledge  base 


Primary  actor 

Local  user 

Stakeholders  and 

interest 

•  Local  user  wants  to  transfer  an  assertion  from  the  local 

database  to  the  external  system/database. 

•  External  system  stores  the  assertions 

Entry  conditions 

•  The  assertion  data  has  been  previously  stored  within 

the  local  database. 

•  The  assertion  data  is  assigned  a  local  ID. 

•  The  local  and  external  systems  are  operational. 

•  The  local  user  is  logged  in  the  system  and  is  on  the 

main  menu. 

Exit  conditions 

•  The  assertion  has  been  successfully  transferred  from 

the  local  database  to  the  external  database. 

•  An  external  ID  is  returned  to  the  local  user  and  stored 

in  the  local  database. 

Main  scenario 

1 .  The  system  displays  a  menu  option,  which  includes  the 

option  to  transfer  assertion  data. 

2.  The  local  user  selects  the  option  to  transfer  an  assertion. 

3.  The  system  displays  an  interface  that  allows  the  user  to 

select  the  assertion(s)  that  will  be  transferred 

4.  The  local  user  selects  the  assertion(s)  and  then  selects 

submit. 

5.  The  system  initiates  a  query  to  the  local  database  for 

the  assertion  data  using  the  local  ID  as  reference. 

6.  The  system  makes  a  copy  of  the  assertion  data. 

7.  The  system  executes  the  KbUpdate  client  system  by 

sending  the  copied  data  over  the  internet  to  the 

31 


external  system. 

8.  The  external  system  redirects  the  data  to  the  external 

knowledge  base  for  storage. 

9.  The  external  system  returns  an  assertion  external  ID(s) 

to  the  sender. 

10.  The  local  system  receives  and  displays  the  external 

ID(s)  to  the  local  user. 

1 1 .  The  system  stores  the  external  ID  in  the  local  database. 

12.  The  system  returns  the  local  user  back  to  the  main 

menu. 

•  The  User  repeats  steps  2-12  until  complete. 

13.  The  local  user  logs  off. 

Extensions 

4a.  Invalid  identification  number: 

1 .  The  system  displays  an  error  message  stating  that  the 

identification  number  entered  was  mal-formed  or 

non-existent. 

2.  The  system  returns  to  the  state  at  step  3  in  the  main 

scenario 

7a.  Network  failure  before  the  assertion  reaches  the 

external  database: 

1 .  The  local  system  displays  an  error  message  stating 

that  a  connection  was  not  completed. 

2.  The  system  returns  to  the  state  at  step  6  in  the  main 

scenario  prior  to  the  transfer  attempt. 

9a.  Network  failure  after  the  transfer  and  before  the 

return  of  the  external  ID. 

1 .  The  system  displays  an  error  message  stating  the 

network  condition. 

2.  The  system  returns  to  the  state  at  step  6  in  the  main 

scenario  prior  to  the  transfer  attempt. 
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User  Transfers  Assertion  Scenario 


Figure  13.  User  transfers  assertion  SSD 


3.  Local  User  Replaces  Assertion  in  the  External  System 
Table  3.  Local  user  replaces  assertion 


Primary  actor 

Local  user 

Stakeholders  and 

interest: 

•  Local  user  wants  to  replace  an  existing  assertion  in  the 

external  database  with  one  from  the  local  database. 

•  External  System  stores  assertions. 

Entry 

conditions: 

•  The  assertion  data  has  been  previously  stored  within 

the  local  database. 
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•  The  assertion  data  is  assigned  a  local  ID. 

•  The  assertion  to  be  replaced  has  been  assigned  an 

external  ID  and  that  ID  has  been  stored  in  the  local 

database. 

•  The  local  and  external  systems  are  operational. 

•  The  local  user  is  logged  in  the  system  and  is  on  the 

main  menu. 

Exit  conditions: 

•  The  old  assertion  has  been  successfully  replaced  by  the 

new  assertion. 

•  An  external  ID  is  returned  to  the  local  user  and  stored 

in  the  local  database. 

Main  scenario: 

1 .  The  system  displays  a  menu  option,  which  includes  the 

option  to  replace  an  existing  assertion  in  the  external 

database. 

2.  The  local  user  selects  the  option  to  replace  an 

assertion. 

3.  The  system  displays  an  interface  that  allows  the  user  to 

select  the  assertion  that  will  replace  the  assertion  in  the 

external  database. 

4.  The  local  user  selects  the  assertion. 

5.  The  system  displays  an  interface  that  allows  the  user  to 

select  the  assertion  that  will  be  replaced. 

6.  The  user  selects  submit. 

7.  The  system  initiates  a  query  to  the  local  database  for 

the  assertion  data  using  the  local  ID  as  reference. 

8.  The  system  makes  a  copy  of  the  assertion  data. 

9.  The  system  executes  the  KbUpdate  client  by  sending 

the  copied  data  and  the  external  ID  of  the  assertion  to 

be  replaced  over  the  internet  to  the  external  system. 

10.  The  external  system  redirects  the  data  to  the  external 
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database  and  replaces  the  assertion  referenced  by  the 

external  ID  storage  with  the  new  assertion. 

1 1 .  The  external  system  returns  a  new  assertion  external 

ID  assigned  to  that  assertion  to  the  local  system. 

12.  The  local  system  receives  and  displays  the  external  ID 

and  a  message  to  the  local  user  indicating  the 

operation  is  complete. 

13.  The  system  stores  the  new  external  ID  in  the  local 

database. 

14.  The  system  returns  the  local  user  back  to  the  main 

menu. 

•  The  User  repeats  steps  2-14  until  complete. 

1 5 .  The  local  user  logs  off. 

Extensions 

4a.  Invalid  identification  number: 

1 .  The  system  displays  an  error  message  stating  that  the 

identification  number  entered  was  mal-formed  or 

non-existent. 

2.  The  system  returns  to  the  state  at  step  3  in  the  main 

scenario. 

9a.  Network  failure  before  the  transfer  takes  place: 

1 .  The  local  system  displays  an  error  message  stating 

that  a  connection  was  not  completed. 

2.  The  system  returns  to  the  state  at  step  6  in  the  main 

scenario  prior  to  the  transfer  attempt. 

11a.  Network  failure  after  the  transfer  and  before  the 

return  of  the  new  identification  number: 

1 .  The  system  displays  an  error  message  stating  the 

network  condition. 

2.  The  system  returns  to  the  state  at  step  6  in  the  main 

scenario  prior  to  the  transfer  attempt. 
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User  Replaces  Assertion  Scenario 
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Figure  14.  User  replaces  assertion  SSD 


4.  Local  User  Edits  Assertion  in  Local  Databas 
Table  4.  Local  user  edits  assertions 


Primary  actor 

Local  user 

Stakeholders  and 

interest: 

•  Local  user  wants  to  ensure  that  the  data  stored  in  the 

local  database  is  updated  correctly. 

Entry 

conditions: 

•  The  assertion  data  has  been  previously  stored  within 

the  local  database. 

•  The  assertion  data  is  assigned  a  unique  identification 

36 


• 

• 

number. 

The  local  system  is  operational. 

The  local  user  is  logged  in  to  the  work  station. 

Exit  conditions: 

• 

The  data  within  the  local  database  has  been  updated 

successfully. 

Main  scenario: 

1. 

The  system  displays  a  menu  option,  which  includes  the 

option  to  edit  a  locally  stored  assertion. 

2. 

The  local  user  selects  the  option  to  edit  assertion. 

3. 

The  system  displays  a  prompt  for  the  user  to  enter  an 

assertion  local  ID. 

4. 

The  local  user  enters  the  local  ID. 

5. 

The  system  retrieves  a  copy  of  the  assertion  data 

displayed  in  an  interface  containing  text  fields  that  are 

populated  with  the  current  data  and  are  capable  of 

being  changed. 

6. 

Local  user  edits  the  data  through  the  interface  and 

selects  the  option  to  save. 

7. 

The  system  reassigns  the  original  assertion  local  ID  to 

this  instance. 

8. 

The  system  generates  a  new  DTG  for  this  instance. 

9. 

The  system  inserts  the  new  data,  DTG,  and  the 

reassigned  local  ID  into  the  local  database. 

10. 

The  system  displays  to  the  user  the  local  ID  and  a 

message  stating  that  the  update  is  complete. 

• 

The  user  repeats  steps  2-10  until  complete. 

11. 

The  local  user  logs  off  the  workstation. 

Extensions 

4a. 

Invalid  identification  number: 

1 

.  The  system  displays  an  error  message  stating  that  the 

identification  number  entered  was  mal-formed  or 

non-existent. 
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2.  The  system  returns  to  the  state  at  step  3  in  the  main 

scenario. 

6a.  Invalid  input: 

1 .  The  system  displays  an  “invalid  input  error”  message 

stating  that  the  data  entered  was  incorrect. 

2.  The  system  returns  to  the  state  at  step  5  in  the  main 

scenario  with  the  original  assertion  data  remains 

unchanged. 

Local  User  Edits  Assertion  Scenario 
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Figure  15.  Local  user  edits  assertion  SSD 
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5. 


External  User  Queries  ExplanationGetWS 


Table  5.  External  user  queries  ExplanationGetWS 


Primary  actor 

External  user 

Stakeholders  and 

• 

The  external  user  needs  information  from  the  local 

interest: 

database. 

• 

The  local  database  has  the  assertion  that  is  being 

requested. 

Entry 

• 

The  assertion  has  been  previously  stored  in  the 

conditions: 

external  database. 

• 

The  assertion  is  currently  stored  in  the  local  database. 

• 

The  assertion  has  been  assigned  an  external  ID. 

• 

The  local  service  is  operational. 

• 

The  external  user  has  already  provided  his/her 

appropriate  authentication  and  has  logged  in  to  the 

external  system. 

Exit  conditions: 

• 

The  assertion  has  been  successfully  retrieved  from  the 

local  system  by  the  external  user. 

Main  scenario: 

1. 

The  external  user  (client)  submits  a  request  for 

assertion  data. 

2. 

The  ExplanationGetWS  receives  the  request,  which 

includes  the  external  ID  of  the  assertion  to  be 

retrieved. 

3. 

Using  the  external  ID  as  a  reference,  the  local  service 

selects  the  respective  data  from  the  local  database. 

4. 

The  data  is  returned  to  the  external  user  via  the 

internet. 

5. 

The  local  service  returns  to  the  state  before  the  initial 

query. 
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• 

The  external  user  repeats  steps  1-5  until  complete. 

Extensions 

la. 

Network  connection  not  available: 

1. 

If  the  network  connection  is  inoperable  the  external 

user  is  presented  with  an  error. 

lb. 

Invalid  identification  number: 

1. 

The  service  interface  displays  an  error  message 

stating  that  the  identification  number  entered  was 

mal-formed  or  non-existent. 

2. 

The  service  interface  returns  to  step  #1  in  the  main 

scenario. 
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Figure  16.  External  user  queries  ExplanationGetWS  SSD 
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6. 


External  User  Queries  StatusReportWS 


Table  6.  External  user  queries  StatusReportWS 


Primary  actor 

External  user 

Stakeholders  and 

interest: 

•  The  external  user  wants  to  verify  the  status  of  the  local 

system  capabilities. 

Entry 

conditions: 

•  StatusReportWS  is  operational. 

•  The  local  capabilities  have  been  assigned  a  status. 

•  The  external  user  provided  the  appropriate 

authentication. 

Exit  conditions: 

•  The  external  user  successfully  receives  the  statuses. 

Main  scenario: 

1 .  The  external  user,  acting  as  the  client,  submits  a 

request  to  StatusReportWS. 

2.  The  local  service  receives  the  request  from  the  external 

user. 

3.  The  local  service  retrieves  the  operational  status. 

4.  The  operations  status  is  returned  to  the  external  user 

via  the  internet. 

5.  The  local  system  returns  to  the  state  prior  to  the  initial 

query. 

•  The  external  user  repeats  steps  1-5  until  complete. 

Extensions 

4a.  Invalid  identification  number: 

1 .  The  system  displays  an  error  message  stating  that  the 

identification  number  entered  was  mal-fonned  or 

non-existent. 

la.  Network  connection  not  available: 

1 .  The  external  user  is  presented  with  a  connection  error. 
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External  User  Queries  StatusReport 
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Figure  17.  External  user  queries  StatusReportWS  SSD 


7  Administrator  Sets  the  Capability  Status 

Table  7.  Administrator  sets  capability  statuses 


Primary  actor 

Administrator 

Stakeholders  and 

interest: 

•  The  administrator  wants  to  ensure  the  appropriate 

status  is  set. 

•  The  external  user  wants  to  occasionally  verify  the 

status  of  the  local  system  capabilities. 

Entry 

conditions: 

•  The  local  service  is  operational. 

•  The  administrator  has  already  provided  proper 

authentication  and  is  logged  in. 

Exit  conditions: 

•  The  administrator  successfully  sets  the  capability 

status. 

•  The  administrator  receives  confirmation  of  the  status 

update. 

Main  scenario: 

1 .  The  system  displays  a  menu  option  that  includes  the 
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option  to  set  the  status  of  the  system  capabilities. 

2.  The  administrator  selects  the  option  to  set  the  status. 

3.  The  system  displays  an  user  interface  to  set  the 

appropriate  status. 

4.  The  administrator  sets  the  status  and  selects  to  the 

option  to  save. 

5.  The  system  updates  the  local  database  with  the 

changes  to  the  statuses. 

6.  StatusReportWS  is  redeployed  to  the  application 

server  reflecting  the  new  statuses. 

7.  The  system  returns  a  message  to  the  administrator 

confirming  the  status  settings. 

8.  The  local  system  returns  to  the  state  at  step  1  in  the 

main  scenario. 

•  The  administrator  repeats  steps  1-8  (if  necessary) 

Extensions 

la.  Connection  to  the  database  is  not  available: 

1 .  The  system  displays  a  database  connection  error. 

2.  The  system  returns  to  the  state  prior  to  step  1 . 
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Figure  18.  Administrator  sets  statuses  SSD 


8.  Administrator  Modifies  a  User  Account 

Table  8.  Administrator  modifies  a  user  account 


Primary  actor 

Administrator 

Stakeholders  and 

interest: 

•  A  local  user  needs  an  account  to  execute  the  system 

operations. 

•  The  Administrator  can  create,  delete,  or  edit  a  user 

account. 

Entry 

conditions: 

•  The  local  system  is  operational. 

•  For  account  creation,  the  new  user  must  not  have  an 

existing  account. 

•  For  account  deletion  or  editing,  the  user  must  have 

existing  account. 

•  The  Administrator  is  already  logged  on  to  the  system. 
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Exit  conditions: 

• 

A  user  account  is  either  successfully  created,  changed, 

or  deleted. 

Main  scenario: 

1. 

The  system  displays  a  main  menu  interface  that 

includes  the  option  to  modify  user  accounts. 

2. 

The  administrator  selects  the  option  to  modify  user 

accounts. 

3. 

The  system  re-prompts  the  system  administrator  for  a 

password. 

4. 

The  administrator  enters  the  password. 

5. 

The  system  displays  an  option  to  either  create  a  new 

user  account  or  edit  a  user  account. 

6. 

The  administrator  selects  the  option  to  create  a  new 

user  account. 

7. 

The  system  displays  an  interface  prompting  for  the 

new  user’s  name,  account  username,  and  account 

password. 

8. 

The  administrator  enters  the  new  username  and 

password. 

9. 

The  administrator  selects  the  option  to  save  the  new 

account  creation. 

10. 

The  system  processes  the  request. 

11. 

The  system  returns  a  message  stating  that  the  account 

has  been  successfully  created. 

12. 

The  system  returns  to  the  state  described  in  step  5. 

• 

The  system  administrator  repeats  steps  5-12  until 

complete. 

13. 

The  system  administrator  returns  to  the  main  menu  and 

logs  off. 

Extensions 

4a. 

Incorrect  Password: 

1 

.  The  system  re -prompts  for  the  system  administrator’s 
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password. 

6a.  Administrator  wants  to  edit  a  user  account: 

1.  The  administrator  selects  the  option  to  edit  a  user 
account. 

2.  The  system  displays  a  list  of  users  that  are  selectable 
and  the  option  to  edit  or  delete  the  selected  account. 

3.  The  administrator  selects  the  user  and  chooses  the 
option  to  edit. 

4.  The  system  displays  an  interface  with  text  fields 
populated  with  the  users  account  information  and 
capable  of  being  manipulated. 

5.  The  administrator  makes  the  changes  to  the  user 
account  and  selects  the  option  to  save.  (Continue 
with  step  #10  in  the  main  scenario). 

6b.  Administrator  wants  to  delete  a  user  account. 

1.  Steps  1  and  2  from  6a  are  performed. 

2.  The  administrator  selects  the  user(s)  and  chooses  the 
option  to  delete. 

3.  The  system  prompts  the  administrator  for 
confirmation  on  the  delete  operation. 

4.  The  administrator  confirms  the  operation.  (Continue 
with  step  #10  on  the  main  scenario). 


Figure  19  displays  the  SSD  for  the  case  in  which  the  administrator  modifies  a 
user’s  personal  account.  Figure  20  extends  from  Figure  19  displaying  the  administrator’s 
choice  of  delete  and  edit.  Both  continue  after  the  administrator  selects  the  option(s)  as 
depicted  within  the  red  box. 
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Administrator  Modifies  a  User  Account 
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Figure  19.  Modify  user  account  (create)  SSD 
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Figure  20.  Modify  user  account  (edit  &  delete)  SSD 


C.  OTHER  FUNCTIONAL  REQUIREMENTS 

The  requirements  listed  in  this  section  are  those  that  were  not  specified  in  the  use 
cases  described  in  Subsection  B. 

1.  System  Access 


1 . 1  A  local  user  is  required  to  have  an  account  in  order  to  use  the  system. 
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1.2  The  user  account  will  include  a  username  and  password. 

1.3  Usernames  will  be  the  user’s  school  email  address. 

1.4  Users  will  not  be  able  to  change  their  passwords. 

1.5  User  passwords  will  be  up  to  15  characters  in  length. 

1.6  User  passwords  can  contain  any  ASCII  character. 

1 .7  User  passwords  will  be  case  sensitive. 

1.8  The  ability  to  manage  the  local  user  accounts  will  be  restricted  to  the  system 
administrator. 

1.9  The  system  administrator  will  have  the  ability  to  grant  or  remove  system 
privileges  to  users,  change  user  passwords,  change  the  system  status,  and  to 
modify  new  user  accounts. 

2.  Database 

2.1  The  Database  Management  System  (DBMS)  will  use  a  server  database  type. 

2.2  The  DBMS  will  support  a  relational  model. 

2.3  The  DBMS  will  utilize  a  Structured  Query  Language  (SQL)  engine. 

2.4  The  DBMS  will  utilize  an  interface  driver  (e.g.,  JDBC,  ODBC). 

2.5  The  DBMS  should  be  able  to  run  on  a  Windows,  Macintosh,  or  Linux 
operating  system. 

2.6  The  DBMS  should  have  a  minimum  database  size  of  4  Gigabytes. 

2.7  The  DBMS  should  be  capable  of  executing,  at  minimum,  the  following  Data 
Types:  integers,  decimal,  strings,  and  date  &  time. 

2.8  The  primary  key  will  be  used  as  the  local  database  assertion  identification. 

2.9  The  DBMS  will  need  to  allow  for  more  than  one  row  of  data  per  assertion. 

2.10  Any  changes  or  service  requests  made  to  the  local  database  must  be  logged 
and  subsequently  be  capable  of  being  queried. 
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3.  Local  System  Functionality 


3.1  When  creating  and  subsequently  storing  an  assertion,  the  user  will  also  have 
the  option  to  either  Store  and  Replace  or  Store  and  Transfer. 

3.1.1  The  Store  and  Replace  function  will  store  the  assertion  in  the  local 
database  and  replace  an  assertion  that  currently  exists  in  the  external 
database. 

3. 1.1.1  When  a  Store  and  Replace  function  is  executed  the  local 
copy  of  the  assertion  that  is  replaced  in  the  external  database  will 
remain  in  the  local  database  with  a  note  replacing  the  respective 
external  ID  stating  a  replacement  has  occurred. 

3.1.2  The  Store  and  Transfer  function  will  store  the  assertion  in  the  local 
database  and  forward  the  assertion  to  the  external  database. 

3.2  When  editing  an  assertion,  the  user  will  have  the  option  to  either  ’edit'  an 
existing  assertion  or  'delete'  an  existing  assertion. 

3.3  When  editing  an  assertion,  the  user  will  be  shown  an  interface  that  displays 
selectable  assertions  with  fields  that  show  the  assertions  have  a  local  ID  and  /  or 
an  external  ID. 

3.3.1  When  the  function  to  'edit'  is  selected  and  both  an  local  ID  and 
external  ID  exist,  the  selected  assertion  will  be  changed  in  the  local 
database  and  the  copy  that  exists  in  the  external  database  will  be  replaced 
by  the  new  version. 

3.3.2  When  the  function  to  'edit'  is  selected  and  only  a  local  ID  exists  for 
the  assertion  then  the  selected  assertion  will  be  changed  in  the  local 
database  only. 

3.3.3  When  the  function  to  'delete'  is  selected  and  only  a  local  ID  exists 
for  the  selected  assertion,  the  assertion  will  be  removed  from  the  local 
database. 
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3.3.4  When  the  function  to  ’delete'  is  selected  and  both  an  local  ID  and 
external  ID  exist,  the  user  will  be  given  an  option  to  either  delete  the 
selected  assertion  from  only  the  external  database  or  from  both  databases. 


3.3.4. 1  If  the  user  selects  to  delete  an  assertion  from  the  external 
database  only,  the  local  copy  of  the  assertion  that  is  removed  from 
the  external  database  will  remain  in  the  local  database  with  a  note 
replacing  the  respective  external  ID  stating  a  deletion  has  occurred. 

4.  Services  and  Clients 

4.1  The  core  capabilities  of  the  system  are  named:  KbUpdate,  ExplanationGetWS, 
DataPush,  and  StatusReportWS. 

4.2  KbUpdate  will  be  a  client  application  that  will  allow  for  the  transfer, 
replacement,  or  deletion  of  assertion  data  to  the  external  system. 

4.2.1  The  local  ID  generated  for  the  assertions  stored  in  the  local  database 
will  be  different  from  the  external  ID  generated  in  response  to  a  KbUpdate 
operation. 

4.2.2  An  assertion  can  only  be  successfully  transferred  once  in  order  to 
avoid  overwriting  the  external  ID  that  was  originally  returned.  This  does 
not  include  replacements. 

4.2.3  Feedback  will  be  returned  in  the  form  of  a  message  to  the  user  either 
during  or  following  the  completion  of  an  operation. 

4.3  ExplanationGetWS  will  be  a  local  port  type  WS  that  will  allow  for  an  external 
user  to  request  assertion  data  from  the  local  database. 

4.3.1  For  the  external  user  to  request  assertion  data  from  the  local 
database,  the  external  ID  needs  to  be  received. 

4.3.2  ExplanationGetWS  will  be  deployed  on  the  local  application  Server. 

4.4  DataPush  will  be  a  client  application  that  is  currently  undefined. 
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4.5  StatusReportWS  will  be  a  local  port  type  WS  that  will  allow  for  an  external 
user  to  request  the  status  of  the  local  system  main  capabilities. 

4.5.1  The  status  returned  to  the  external  user  consists  of  a  status  message 
and  a  DTG  for  the  time  when  the  operation  was  last  performed. 

4.5.2  A  status  will  be  assigned  to  each  of  the  three  key  capabilities: 
DataPush,  ExplanationGet,  and  KbUpdate. 

4.5.3  The  Web  service  status  message  can  be  a  choice  between  being 
’Available,'  ‘Unavailable,’  or  'Unsupported.' 

4.5.4  StatusReportWS  will  be  deployed  on  the  local  application  server. 

5,  User  Interface  (UI) 

5.1  The  UI  will  be  a  Web  application  based  on  a  local  client  /  server  system  that 
consists  of  web  pages  a  user  can  access  with  a  Web  browser  to  execute  the  main 
system  operations. 

5.2  The  use  of  the  UI  will  be  restricted  to  the  local  users. 

5.3  The  UI  will  consist  of  a  sign-in  page  and  a  main  menu  page  with  connecting 
Web  pages  to  facilitate  executing  five  main  operations:  storing  assertions, 
transferring  assertions,  editing  assertions,  setting  the  capability  statuses,  and 
managing  user  accounts. 

5.3.1  The  sign-in  page  will  provide  text  fields  to  enter  user  sign-in  data 
and  a  means  to  cancel  the  operation. 

5.3.2  The  main  menu  will  allow  the  user  to  navigate  to  all  five  main 
operations  described  in  3.2. 

5.3.3  The  main  menu  will  provide  the  user  the  means  to  log  out  of  the 
system. 


52 


5.3.4  The  main  menu  will  display  a  list  of  the  10  most  recently  executed 
activities  associated  with  core  system  capabilities  along  with  their 
respective  DTG. 

5.3.5  The  main  menu  will  allow  the  user  to  check  executed  activities  that 
are  not  among  the  10  most  recent. 

5.3.6  The  main  menu  will  display  the  current  capability  statuses. 

5.3.7  The  Transfer  Assertion  and  Edit  Assertion  pages  will  provide  a 
browsing  capability  for  the  user  to  look  up  and  select  assertions. 

5.3.8  The  functions  under  the  Store  Assertion,  Transfer  Assertion,  and 
Edit  Assertion  Web  pages  that  either  send  assertion  data  to  the  external 
database,  replace  an  existing  assertion  in  the  external  database,  or  delete 
an  existing  assertion  from  the  external  database  will  execute  the  KbUpdate 
client. 

6.  Application  Server 

6.1  The  application  server  must  be  JAVA  Enterprise  Edition  compliant. 

6.2  The  application  server  must  provide  a  runtime  for  Web-based  applications. 

6.3  The  application  server  must  allow  for  the  deployment  of  Java  Server  Pages 
and  Servlets. 

D.  NONFUNCTIONAL  REQUIREMENTS 

These  requirements  express  specific  nonfunctional  attributes  of  the  system’s 
environment. 

1.  Usability 

1.1  The  intended  user  is  one  which  should  be  comfortable  with  the  basic 
functionality  of  a  Web  browser,  which  will  allow  for  the  manipulation  of  an 
assertion. 
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1.2  The  software  must  be  consistent  with  standard  Web  browser-based 
applications. 

2.  Reliability 

2.1  The  system  services  must  be  consistently  available  24  hours  a  day  during  the 
project  period. 

2.2  Mean  time  to  repair  will  be  less  than  1  hour. 

2.2  Upon  a  system  crash  and  recovery  the  database  data  must  be  safe  and 
represent  what  it  had  prior  to  the  crash. 

3.  Portability 

3.1  The  software  must  be  portable,  meaning  that  the  program  must  be  capable  of 
being  executed  from  a  Java  Archive  file  (.jar)  and  /  or  a  Web  application  archive 
file  (.war). 

3.1.1  The  portable  executable  files  must  be  compatible  with  the  Glassfish 
version  3  Application  Server. 

4.  Supportability 

4.1  The  software  must  be  capable  of  accommodating  updates  to  the  XSD,  WSDL, 
or  general  changes. 

4.2  The  program  code  must  be  well  commented  to  allow  for  future  analysis  and 
modification. 

4.3  The  program  code  must  be  well  commented  modular  code  to  support  testing 
procedures. 
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E. 


SUMMARY 


In  this  chapter,  we  provided  an  SRS  for  our  proposed  distributed  system.  The  SRS 
utilized  use  cases  to  demonstrate  the  functional  requirements  and  those  specific 
requirements  not  mentioned  in  the  use  cases  were  explained  in  sub-section  C.  The 
sequence  diagrams  were  created  to  demonstrate  the  interaction  of  the  processes  which 
would  be  needed  to  execute  the  core  operations  and  also  the  order  in  which  they  would 
perform.  We  used  these  requirements  to  help  us  design  the  proposed  system  that  is 
covered  in  Chapter  IV. 
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IV.  SYSTEM  DESIGN 


This  chapter  presents  a  design  of  the  proposed  distributed  system  based  on  the 
requirements  defined  in  Chapter  III.  We  have  broken  down  the  system  into  four  main 
tiers  to  be  developed  as  depicted  in  Figure  21.  The  four  tiers  represents  the  fundamental 
architecture  that  our  client  application  and  service  will  use  for  deployment. 


Database 

Tier 


Remote 

Client 


Figure  2 1 .  Four  tiers  of  development 


A.  DATABASE  TIER 

Based  on  the  stakeholder’s  requirement  of  a  relational  database  mentioned  in 
Chapter  III,  our  first  step  was  to  build  a  conceptual  data  model  (CDM)  of  the  underlying 
database  schema.  A  CDM  is  high-level  visual  representation  that  uses  concepts  such  as 
entities,  attributes,  and  relationships  to  describe  a  database  application  (Elmasri  & 
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Navathe,  2007).  Specifically,  we  will  use  an  entity-relationship  (ER)  diagram,  which  is  a 
popular  type  of  CDM,  to  represent  our  database.  To  avoid  redundancy  while  ensuring 
scalability,  we  normalized  our  database  by  using  an  algorithm  that  performs  several  steps 
to  map  an  ER  diagram  into  a  Relational  Database  Schema  (RDS)  (Elmasri  &  Navathe, 
2007).  Figure  22  shows  our  ER  diagram.  To  clarify  what  our  ER  diagram  depicts,  we  will 
briefly  discuss  what  the  aforementioned  concepts  found  in  CDMs  mean. 

•  Entities  represent  a  thing  (conceptual  or  physical)  in  the  real  world  that 
exists  independently.  In  our  diagram  entities  are  depicted  as  the  green 
rectangular  boxes.  Entities  that  have  an  additional  outline  around  the 
rectangle  are  called  weak  entities,  which  means  that  they  do  not  have  a  key 
attribute  and  are  related  to  a  specific  entity  called  the  owner  entity 
(Elmasri  &  Navathe,  2007). 

•  Attributes  are  specific  properties  of  an  entity.  Attributes  that  are 
underlined  are  considered  to  be  key  attributes,  which  means  that  they  are 
unique  in  value.  Attributes  are  depicted  as  yellow  circles.  Multi-valued 
attributes  are  depicted  with  a  double  circle  and  represent  data  that  can  be 
greater  than  one  set.  Composite  attributes  are  those  that  have  additional 
sub-attributes  (e.g.,  the  sub-attributes  for  a  person’s  address  are:  street 
number,  street  name,  zip  code,  city,  and  state).  Composite  attributes  are 
displayed  with  extra  lines  attached  to  their  sub-attributes. 

•  Relationships  can  exist  between  entities  and  serve  to  describe  an 
association  between  them.  Relationships  are  depicted  as  orange  diamonds 
and  those  having  an  additional  outline  around  the  diamond  relate  weak 
entities  to  its  owner  entity  (Elmasri  &  Navathe,  2007).  The  number  1  or 
letters  N  and  M  adjacent  to  the  relationship  represent  a  cardinality  ratio 
that  depicts  the  maximum  number  of  instances  that  an  entity  can 
participate  in  (e.g.,  1:N  means  a  one-to-many  relationship). 
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1. 


ER  Diagram 


In  our  ER  diagram,  we  listed  LocalUserAccounts  as  a  regular  entity  with  the  user 
email  attribute  as  the  key  attribute.  LocalUserAccounts  is  an  owner  entity  that  shares  a 
1:N  relationship  ’Sets_the'  with  the  weak  entity  called  CapabilityStatus.  Since  only  one 
user  (system  administrator)  can  set  the  capability  status  this  type  of  association  between 
entities  is  called  partial  participation  and  is  displayed  as  a  single  line  connecting  the 
relationship  to  the  entities.  LocalUserAccounts  shares  a  1  :N  relationship  'Manages'  with 
itself,  which  represents  the  system  administrator’s  ability  to  manage  user  accounts. 
LocalUserAccounts  also  shares  a  M:N  (many-to-many)  relationship  'Creates_an'  with  a 
regular  entity  Assertion,  whose  key  attribute  is  Local  lD.  The  double  lines  extending 
from  LocalUserAccounts  to  Assertion  represents  an  association  between  entities  called 
total  participation,  which  means  that  all  local  users  can  create  an  assertion  (Elmasri  & 
Navathe,  2007).  Assertion  is  an  owner  entity  type  that  shares  a  1:1  relationship  with 
DataSource,  KbEvidence,  KbSupport,  and  a  KbClaim.  These  weak  entities  are  the 
major  elements  of  an  assertion  that  have  been  determined  by  the  SCIL  stakeholders  thus 
far.  DataSource  is  a  new  element  that  is  currently  under  evaluation  so  we  decided  to 
include  this  element  into  our  design. 
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Figure  22.  Database  ER  diagram 


2.  Relational  Database  Schema 

Taking  the  ER  diagram  developed  in  our  first  step  we  used  the  following  steps  to 
map  the  ER  diagram  into  a  Relational  Database  Schema  (RDS).  The  schema  in  turn 
guides  the  design  of  the  database  tables. 

a.  Mapping  of  Regular  Entity  Types 

Figure  23  displays  the  RDS,  which  initially  includes  LocalUserAccount 
and  Assertion.  They  are  both  assigned  their  own  relation  with  email  and  locallD, 
respectively,  as  their  primary  keys. 
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LocalLser  Account  firslName  luslNanie  email  password 


c.  Mapping  of  Binary  1:1  Relationship  Types 

In  step  3,  we  merged  all  of  the  weak  entity  relations  created  in  step  2  with 
their  owner  entity  (Assertion)  keeping  locallD  as  the  primary  key. 


61 


LocalUser Account  firstName  lastName  email  password 


Assertion 


locallD 

extID 

dtg 

flag 

tlieoFraine 

speaker  ID 

speakei  Type 

version 

Pi  edNaine 

strength 

display 

lan  gU  seD  om  ain 

sourceMedium 

sourceType 

sourceLoc 

soui ceL  ang 

sourceName 

CapabilityStatus  kbuStatus  dpStatus  egStatus  kbuDTG  dpDTG  egDTG 


Figure  25.  Mapping  of  binary  1:1  relationship  types 


d.  Mapping  of  Binary  1:N  Relationship  Types 

In  step  4,  we  added  foreign  keys  in  both  CapabilityStatus  and 
LocalUserAccount;  both  of  which  refer  to  LocalUserAccount’s  primary  key:  email. 


Figure  26.  Mapping  of  binary  1:N  relationship  types 


e.  Mapping  of  Binary  M:N  Relationship  Types 

In  step  5,  we  create  a  new  relation  called  ’Creates  an’  that  houses  two 
foreign  keys  referring  to  the  primary  keys  in  LocalUserAccount  and  Assertion. 
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Figure  27.  Mapping  of  binary  M:N  relationship  types 


f  Mapping  of  Multivalued  Attributes 

Finally,  in  step  6,  we  map  the  multivalued  attributes  to  their  own  relations 
containing  their  respective  attributes  along  with  a  foreign  key  that  refers  to  the  primary 
key  of  Assertion.  Figure  30  depicts  the  proposed  database  tables  that  will  be  created  for 
the  system.  The  table  names  are  the  relation  names  on  the  side  of  the  attributes  and  the 
column  names  are  the  attributes  themselves.  We  populated  the  database  with  sample  data 
and  we  will  discuss  that  process  in  Chapter  V. 
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Figure  28.  Mapping  of  multivalued  attributes 


B.  BUSINESS  LOGIC  TIER 

1.  XML  Schema 

In  Chapter  II,  we  discussed  XML  schemas  and  their  significance.  In  this  section 
we  present  aspects  of  the  XML  schema  related  to  our  client  and  services.  The  schema 
was  generated  by  Richard  Tong,  a  representative  from  IARPA-Scientific,  Engineering 
and  Technical  Assistance  branch.  As  of  May  4,  2010  the  current  version  of  the  schema  is 
1.2.  We  modified  and  renamed  the  schema  in  order  to  accurately  reflect  the  structure  of 
the  assertions  agreed  on  by  the  UMD  stakeholders.  We  also  employed  two  versions  of  the 
schema,  one  for  our  Web  services  and  one  for  our  client.  By  doing  so,  we  were  able  to 
remove  the  XML  syntax  that  did  not  pertain  to  the  respective  operations,  which  made  the 
lines  of  XML  easier  to  manage  and  sped  up  the  program  compilation  process.  The 
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StatusReportWS  and  ExplanationGetWS  services  utilize  UMDSchema_12b.xsd.  The 
KbUpdate  client  uses  STEPSchema_12b.xsd.  In  the  Appendix,  we  have  listed  one 
schema  that  includes  the  data  types  and  elements  defined  in  both  versions. 


a.  StatusReportWS 

The  schema  element  StatusReportResponseMsgPart,  shown  in  Figure  29, 
represents  the  service  response  to  the  incoming  request.  It  is  constructed  with  two  sub¬ 
elements:  Metadata  and  Payload. 

<xs:element  name-’StatusReportResponseMsgPart"> 

<xs  annotations 
<xs:complexType> 

<xs  sequences 

<xs:element  name="Metadata"s 
<xs:complexTypes 
<xs  sequences 

<xs:element  name- Messageld"  type- 'xs:string"> 

<xs  annotations 
i  i  </xs:elements 

<xs:element  name-'Requestorld"  type="xs  string"> 

<xs  annotations 
|  </xs  elements 
|  </xs:sequences 

</xs:complexType> 

</xs  elements 

<xs:element  name="Payload''s 
<xs:complexTypes 
|  <xs  sequence* 

<xs:element  name="StatusReturnBundle"  type-'stepd:StatusRetumBundle7s 
i  </xs  sequences 
i  </xs:complexTypes 

</xs  elements 
I  </xs:sequences 
[  </xs:complexTypes 
</xs:element> 


Figure  29.  XML  schema  StatusReportResponseMsgPart 


Metadata  is  composed  of  the  message  and  requestor  identification  that  is 
submitted  in  the  request  and  is  subsequently  returned.  The  Payload  element  holds  a 
sequence  of  sub-elements  and  types,  including  StatusRetumBundle,  that  eventually 
provide  the  capability  status. 

Figure  30  shows  the  ServiceStatusReport  type  that  holds  the  individual 
client  and  service  capability  status.  Although  not  depicted  for  brevity,  each  sub-element 
capability  is  composed  of  a  State  and  a  LastDtg.  The  State  is  of  type  ServiceState  that  is 
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the  simple  type  described  on  the  top.  LastDtg  is  of  type  dateTime,  which  is  an  integer¬ 
valued  year,  month,  day  and  time  structure  (W3C,  2004). 


<xs  simpleType  name="ServiceState"> 

<xs  annotation 

<xs  restriction  base-'xs  string"> 
j  j  <xs  enumeration  value="availab)e’7> 

<xs  enumeration  value="unavailable7> 
j  j  <xs  enumeration  value- ’unsupported7> 
i  </xs:restriction> 

<yxs:simpteType> 

<xs  complexType  name=- ServiceStatusReport  "> 

<xs  annotation> 

<xs  sequence> 

|  <xs  element  name=  "KbUpdateCapatxlity"> 

<xs  annotation> 

<xs  complexType> 

|  I  j  j  <xs  sequence> 

<xs  element  name="State"  type='  stepd  ServiceState"/> 

|  <xs:element  name-'LastDtg"  type-xs  dateTime"/> 
</xs:sequence> 

!  </xs  complexType  > 
j  j  <yxs.element> 

|  <xs  element  name="DataPushCapab<lity"> 

|  <xs  element  name="ExplanationGetCapability"> 

</xssequence> 

<Jxs  complexType> 

Figure  30.  XML  schema  ServiceState  and  ServiceStatusReport 


b.  ExpIanationGetWS 

Figure  31  shows  the  ExplanationGetResponseMsgPart,  which  is  the  root 
element  that  comprises  the  message  to  be  returned  to  the  client.  In  similar  fashion  to 
StatusReport,  it  contains  a  Metadata  and  Payload.  The  Payload  houses  an 
ExplanationRetumBundle  that,  although  not  depicted,  also  has  a  set  of  Metadata  and 
Payload.  This  sub-Metadata  holds  the  Assertionld  that  references  the  particular  data  to  be 
obtained  from  our  database.  The  sub-Payload  subsequently  contains  the  main  elements 
that  make  up  an  assertion  that  are  listed  under  the  complex  type  Kb  Assertion  in  Figure 
32.  Although,  in  concept,  the  key  elements  to  an  assertion  remain  as  the  claim,  evidence, 

and  support,  the  KbAssertion  is  made  up  of  two  elements,  the  AssertionMetadata  and 
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AssertionContext.  However,  AssertionClaim,  AssertionSupport,  and  AssertionEvidence 
are  of  separate  individual  types  that  are  further  defined  in  Figures  34,  35,  and  36. 

<xs  element  name-’ExplanationGetResponseMsgPart"? 

|  <xs.annotation> 

|  <xs  complexType? 

I  <xs:sequence> 

|  ]  <xs  element  name- "Metadata'? 

I  <xs  complexType? 

M  M  <xs. sequence? 

|  |  M  |  j  <xs  element  name^’Messageld"  type- 'xs  stnng"> 

|  |  j  I  |  ;  ;  <xs: annotation? 
j  j  i  <Vxs  element? 

I  M  !  I  <xs:  element  name='Requestodd*type="xs:string*> 

!!  !  j  j  I  |  <xs  annotation? 

j  <Jx s  element? 

|  |  j  |  |  </xs  sequence? 

;  |  j  j  </xs:complexType? 

1  |  1  </xs  element? 

<xs:  element  name=  Payload'? 

|  |  \  ]  <xs  complexType? 

1  j  |  |  j  <xs  sequence? 

I  |  !  <xs:element  name="ExplanationRetumBundle' type="stepd  ExplanationReturnBundle"/? 

M  M  </xs- sequence? 

1  !  f  j  </xs:complexType? 

|  j  </xs  element? 
j  j  <Vxs  sequence? 

I  </xs:complexType? 

</xs  element? 

Figure  3 1 .  XML  schema  ExplanationGetResponseMsgPart 


AssertionMetadata  is  composed  of  three  elements  including 
AssertionFlag,  which  is  also  defined  in  the  schema.  The  AssertionFlag  is  designed  as  an 
enumeration  of  the  value:  ’Public’  and  ’Private,’  which  represent  viewing  authorization 
labels  for  the  assertion.  AssertionContext  has  an  element  called  DataSet  that  is  of  type 
DataSource.  Figure  33  shows  DataSource.  The  elements  and  types  defined  within 
KbClaim,  KbEvidence,  and  KbSupport  were  specified  by  the  UMD  teams. 


67 


<xs  complexType  name-KbAssertion‘> 

<xs  sequences 

I  <xs  element  name='Asse!tionMetadata  ’> 

I  <xs  complexTypes 
:  |  •  i  <xs  sequences 

j  j  ;  j  <xs.element  name~"Assertionld"  lype-"xs:strintf> 
i  j  <xselemenl  name- Ass  edionDtg-  type-'xs  datsTime's 
|  j  j  <xs  element  name='  AssertionFlag”  type-  stepd  AssertianFlag*> 
i  ■  !  </xs  sequences 
j  j  </xs  complexTypes 
I  <j'xs  elements 

;  <xs  element  name='AssertionContexr> 

|  <xs:complexType> 

!  j  |  <xs. sequences 

<xs  element  name-'  LanguagellseDoma-n'  type='xs  string’  ^fault^'Persuasion  Attempt' s 
j  j  i  ;  <xs  element  name- DataSet'Type=' stepd  DataSource's 
i  j  ;  </xs  sequences 
|  j  </xs  complexTypes 
|  </xselements 

|  <xs:element  "ame='AsserrionClaim'Type='stepd:KI>Clatrn7s 
i  <xs. element  "ame^-AssertionEvidence"  :ype='siepd:KbEvidence7> 

<xs  element  name='AssertionSupporT  type=’stepd  KbSupport'Vs 
<txs  sequences 
</xs  complexTypes 

Figure  32.  XML  schema  KbAssertion 


<xs  complexType  name- ‘DataSourc  e’’> 

<xs:  annotations 
<xs  sequences 

<xs  element  name- 'Data  Metadata's 
<xs:annotation> 

<xs  complexTypes 
i  I  <xs  sequences 

11:1  <xs  element  name="SourceName“  type=''xs:strlng"> 
ill;  <xs  element  name=''SourceLocation"  type-'xs  anyURI's 

I  <xs  element  name="SourceLanguage"  type='xs  language's 
j  j  •  <xs  element  name="SourceType~  type="xs:stnng"> 

|  <xs  element  name="SourceMedium"  type='xs  string's 
j  I  </xs  sequences 
;  I  </xs:comptexType> 
j  </xs  elements 

|  <xs  element  name="DataSegment"  minOccurs=“0"  maxOccurs="unbounded"s 
<xs  annotations 
<xs  complexTypes 
j  I  j  <xs  sequences 

j  <xs  element  name=’SourceDataSegment"  type="xs:stnng"/> 
i  I  j  </xs  sequences 
</xs:complexTypes 
I  </xs  elements 
</xs  sequences 
</xs:complexType> 

Figure  33.  XML  schema  DataSource 
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<xs  complexType  name="KbClaim"s 
<xs  sequences 

<xs  element  name- PredicateClamV's 
:  <xs  complexTypes 
<xs  sequences 

i  :  j  i  <xs  element  name-'PredicateName"  type- xs  stnng"  default=  Persuasion  Attempt7> 

i  i  ;  I  <xs  element  name- Speaker  > 

i  ;  i  I  !  |  <xs  complexTypes 

j  [  j  j  |  I  <xs. sequences 

j  i  j  j  {  I  I  <xs. element  na-  e="Entity"  type="stepd:Enlily7> 

|  j  j  j  j  j  j  </xs  sequences 

!  j  j  !  j  <yxs. complexTypes 

|  [  j  j  j  </xselement> 

j  j  j  j  j  <xs  element  name- Target'  s 

j  i  |  <xs:complexTypes 

|  |  [  ■  j  |  :  <xs:sequence> 

i  |  |  I  i  i  |  <xs  element  na~e-"Entity"  type- stopd  Entity"  maxOccurs="unbounded7> 

i  j  i  i  '  </xs:sequences 

i  j  j  !  j  j  <xs:attribute  name-'type '  type="xs  stnng"  default='directed"> 

I  •  <VxscomplexType> 

M  j  j  i  <^xs  elements 

I  j  !  j  <Jxs  sequences 
i  i  </xs  complexTypes 
I  </xs  elements 
i  </xs  sequences 
</xs  complexTypes 


Figure  34.  XML  schema  KbClaim 


<xs  complexType  name="KbEvidence"> 

<xs  sequences 

j  i  <xs  element  name-"EvidenceValue"type="xs:string's 
j  j  <xs  element  name-"Evider.ceStatement "  type='stepd  EvidenceStatement  '/s 
j  </xs  sequences 

</xs :  complexT  ype> 

<xs  complexType  name="EvidenceStatemenf> 

I  <xs:sequence> 

i  <xs  element  name='ConstituentMultiset''s 
j  1  <xs:complexTypes 

|  <xs  sequences 

i  i  i  I  <xs  element  r.ame='PersuasionTactic"  maxOccuis-'untxjunded’s 

:  !  :  : 

;  MM  <xs: complexTypes 

I  I  M  M  <xs  group  tef=*stepd  PersuasionTacticGroup7> 

|  </xs:complexTypes 
|  }  j  j  </xs  elements 

!  j  </xs:sequence> 
i  j  </xs  complexTypes 

</xs  elements 
|  </xs:sequence> 

</xs  complexTypes 

<xs  group  na  me="PersuasionT acticGroup's 
<xs  alls 

|  <xs:element  name='tactlc"  type='xs:stnng"/> 

j  <xs  element  name="startline"  type="xs  integer"/s 

<xs  element  name-"endline"  type- xs  mteger"/s 
•  <xs  element  name="doc"  type='xs  stnng'Ts 

|  </xsall> 

</xs:groups 


Figure  35.  XML  schema  KbEvidence 
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<xs  complexType  name=  KbSupporf> 

|  <xs  sequence> 

i  <xselement  name=TheoreticalFrame"  type="xs:string"/> 

|  <xs  element  name=TechnicalTerm'  maxOccurs-'unbounded'  > 

<xs  complexly pe> 

|  !  |  <xs  sequence> 

<xs  element  name='TechnicafTermGloss"  type="xs  string7> 

|  III  <xs  element  name="DataSnippet"  type="xs  string7> 

|  |  j  </xs  sequence> 

<xs  attnbute  name="term“  type="xs:string"  default=‘  redefinition7> 
I  i  </xs  complexType> 

;  </xs  element > 

|  </xs.sequence> 

</xs  complexType> 

Figure  36.  XML  schema  KbSupport 


c.  KbUpdate  Client 

KbUpdate  is  a  client  and  the  KbUpdateRequestMsgPart,  pictured  below,  is 
the  root  element  comprising  our  request  message  to  the  external  system.  The  request  is 
sent  to  the  external  system  to  update  the  external  knowledge  base  with  assertion  data.  The 
request  can  either  add  a  new  assertion,  delete  a  existing  assertion,  or  replace  an  existing 
assertion  from  the  external  database.  As  depicted,  the  request  contains  Metadata  and 
Payload.  The  Metadata  contains  a  message  identification  and  the  requesting  team 
identification.  The  Payload  is  composed  of  an  option  of  element  bundles  representing  the 
desired  type  of  update.  Figure  38  displays  the  AssertionAddBundle.  The 
AssertionAddBundle  element  has  Metadata  that  addresses  the  number  of  assertions  to  be 
updated  and  is  called  AssertionCount.  The  Payload  contains  the  element  Assertion  and 
references  the  same  elements  and  types  previously  defined  in  the  ExplanationGet 
description. 
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<xs:element  name="KbUpdateRequestMsgPait'> 

;  <xs:annotation? 

<xs  complexType> 

:  j  <xs  sequence? 

{  |  I  <xs  element  name=' Metadata'? 

I  <xs:comptexType> 

|  I  f  |  |  <xs: sequence? 

ill  <xs  element  name=  "Messageld"  type="xs  string"? 

I  |  <xs  element  name- Teamld"  type-'stepd  Teamld"? 

?M]j  </xs  sequence? 

;  I  </xs:complexType> 

I  </xse!ement> 

<xs  element  name="Paytoad"> 

I  I  I  I  <xscomplexType> 

I  I  I  !  I  <xs  choice? 

j  <x$  element  name-' AssertionAddBundle"  type-'stepd  AssertionAddBundle”/? 

j  <xs  element  name="AssertionReplaceBundle"  ty  pe="stepd:AssertionReplaceBundle'7? 

j  <xs:element  name="AssertionDeleteBundle”  type="stepd:AssertronDeleteBundle7? 

I  I  I  I  I  </xs:  choice? 

I  I  I  |  </xscomplexType? 

1  I  </xs  element? 

[  I  </xs  sequence? 

I  </xs  complexType? 

</xs  element? 


Figure  37.  XML  schema  KbUpdateRequestMsgPart 


: 


1  !  ! 


<xs  complexType  name="AssertionAddBundle"> 

<xs:  annotation? 

<xssequence? 

<xs  element  name="Metadata"> 

<xs:complexType> 

<xs  sequence? 

<xs  element  name="AssertionCount"> 

<xs  annotation? 

<xs  simpteType? 

<xs:restriction  base- 'xs integer' ? 

<xs:minlnclusive  value="T7> 

</xs  restriction? 

|  <Jx s  simpleType? 

</xs:element? 

</xs:sequence? 

|  </xscomplexType? 

</xs  element? 

<xs  element  name="Paytoad"> 

|  <xs  complexType? 

<xs:sequence? 

<xs  element  name="Assertion"  type="stepd  KbAssertion"  maxOccurs=’'unbounded'? 
</xs  sequence? 

|  </xs  complexType? 

</xs:  element? 

</xs:  sequence? 

</xs  complexType? 


1  ! 


I  I 


Figure  38.  XML  schema  AssertionAddBundle 
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The  AssertionDeleteBundle  (Figure  39)  also  contains  Metadata  and 
Payload  elements.  The  Metadata  is  similar  to  the  AssertionAddBundle,  however  now  the 
AssertionCount  refers  to  the  number  of  assertions  to  be  deleted.  The  Payload  on  the  other 
hand  refers  to  the  particular  identification  number  of  the  assertion(s)  to  be  deleted.  The 
AssertionReplaceBundle  (Figure  40)  uses  the  same  Metadata  and  Payload  structure 
where  the  AssertionCount  refers  to  the  number  of  pairs  of  assertions  to  be  swapped.  The 
Payload’s  sub-elements  describe  both  the  identification  number  of  the  assertion  from  the 
external  database  to  be  replaced  and  the  particular  assertion  from  the  local  database  that 
will  replace  it.  Again,  this  Assertion  is  of  type  KbAssertion  described  in  the 
ExplanationGet. 

<xs  complexType  name="AssertionDeleteBundle"> 

|  <xs:annotation> 

<xs:sequence> 

[  |  <xs  element  name= 'Metadata'';* 
i  <xs  complexType> 
j|j!  <xssequence> 

Mill  <xs:element  name=*AssertionCount"> 

i  i  i  i  : 

|  |  j  }  </xs:  sequence:* 

|  j  |  </xs  complexType> 

|  j  </xs:element> 

<xs  element  name=”Payload"> 
j  <xs:complexType> 

<xs:sequence> 

I  |  <xs  element  name="A$ser1ionld"  type="xs  string"  maxOccurs="unbounded"> 
j  j  ]  |  </xs  sequence> 

!  |  </xs:complexType> 
j  </xs:element> 
j  </xs  sequence;* 

</xs  complexType> 

Figure  39.  XML  schema  AssertionDeleteBundle 
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<xs  complexType  name="AssertionReplaceBundle'> 

<xs  annotation? 

<xs  sequence? 

|  <xs  element  name=' Metadata”? 

<xscomplexType> 

<xs:sequence> 

Mi!  <xs  element  name="AssertionCount"> 
j  j  I  </xs  sequence> 
j  |  </xs  complexType? 
j  </xs. element? 
j  <xs  element  name="Payload"> 

|  |  <xs  complexType? 

I  j  j  <xs  sequence? 

<xs  element  name="A$sertlonPair"  maxOccurs=”unbounded'  > 

|  ]  |  I  |  <xs  annotation? 

|  |  j  |  |  <xs  complexType? 
j  j  j  :  <xs  sequence? 

i  I  <xs  element  name=  ReplacedAssertionld"  type="xs:string''> 
!  I  |  |  <xs  element  name='Assertion'’  type="stepd:KbAssertion''> 

|  |  |  |  j  </xs  sequence> 

!  I  I  I  j  </xs:complexType> 

|  |  |  {  </xs:element> 

|  i  ;  </xs  sequence> 
j  j  </xs  complexType> 

|  </x s  element> 

</xs  sequence? 

</xs  complexType? 

Figure  40.  XML  schema  AssertionReplaceBundle 


2.  Class  Diagrams 

Earlier,  we  showed  the  readers  our  proposed  domain  model  that  provided  a 
conceptual  perspective  of  the  system  as  a  whole.  In  this  section,  we  used  the  same  UML 
modeling  notation  to  provide  class  diagrams  that  provide  the  software-focused  structural 
view  of  the  system,  with  the  main  elements  indicated  by  boxes.  Each  box  contains  three 
sections:  name  (top  section),  attributes  (middle  section),  and  functions  (bottom  section). 
In  the  following  sections,  we  will  walk  through  the  class  diagrams  for  our  StatusReport 
service,  ExplanationGet  service,  and  KbUpdate  Client. 
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a.  StatusReport 


Figures  41  and  42  display  the  class  diagram  for  the  StatusReport  service. 
Class  StatusReport  implements  the  client  interface  SR  PortType  and  is  dependent  on  the 
request  message  received  that  is  of  the  type  StatusReportRequestMsgPart.  The  message 
will  contain  both  a  message  ID  and  a  requester  ID  (Metadata),  which  are  eventually 
returned  to  the  client  as  part  of  the  StatusReportRequestMsgPart  along  with  the 
Payload.  This  Payload  class  refers  to  a  StatusReturnBundle  class,  which  also  has  a 
sub-class  called  Payload  that  refers  to  the  class  ServiceStatusReport.  ServiceStatusReport 
has  the  three  subclasses,  which  hold  the  methods  that  work  closest  to  the  Database 
class  in  order  to  get  the  information  from  the  database.  KbUpdateCapability, 
ExplanationGetCapabiltiy,  and  DataPushCapability  refer  to  the  ServiceState  class,  which 
holds  an  enumeration  of  string  literals:  Available,  Unavailable,  or  Unsupported.  Finally 
the  Database  class  implements  the  Connection  interface,  which  provides  the  methods  for 
interacting  with  our  database.  The  Connection  class  is  a  Java  2  platform  object 
(http://download.oracle.eom/docs/cd/E17476_01/javase/l.3/docs/api/java/sqFConneetion.html). 


74 


Metadata 


ffroes^aseid- String 
srequestorid:  btriru 


*-getMesi  dtri  d|  j:  rressaield 

*  s*t  Message!  <J(in  value:  String) 

♦  gnfflrque^trrifUl  rrqur.torid 
*s«tfl«us5torlcKi“  value.  Str  na} 


Metadata 


sm^sageld  5*rin£ 
sr*qufitofl  d  Srrrg 


-se'tMwsap-ldY  nesszge  d 
«ietfAasise  din  vabt  Strin) 
•grP.earstarii’  r  rfqjrstcrri 
•seflleq  jested  d':n  sal  js:  Jtnnjl 


StatusReportRequestMsgPart 


:  metadata:  StawsReportReq  uestMsgPart  .Metadata  ^  —  , 


-  gclMeladatiQ:  metadata 

-  setMetadata(in  value) 


StXudtcfUtRrfnnvNfcgl’iri 


«  nKticafe  SU'Js'tffatRcw'H'MagPir.Mraiata 
•attend:  StmidtoatScspoiorM^Pait  PlykBd 


-grtNfctadatiij  ortadra 

•  seS.fcalir.a:'tnta;uc:  StausR^-MtRcspGiRMEafjr.ifcQdiui 

•  gKPsybsd l  psytoad 

-RtPiv]iHCj:ir.vu^  5tatusRej)retRtspinKJi|Pait?iy!oa<l) 


«Inter6ce» 

SlalusRjportPort'lyp^ 


+  s*atusReport(it)  statosRequest) 


StalUsRcpurt 


+  gvtStotusRepoiliiu  fftaliisRequest) 


Payload 


artatjsaeajne  j-de:i:itusF«:u-r6jrde 


feStatinaaiTijrdfell 

-se:Sitiifet.rr3ti>l  s>3  if:  Stat.sSEtjrrfiL'Tdle! 


I 


SratusReturnBundle 


#  payload:  StatusRetumBundlePavload 


+  getPayloadO  payload 

t  setPavload( in  value) 


l 


SeniwSlatusReport 


Figure  4 1 .  StatusReport  class  diagram  part  I 
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Figure  42.  StatusReport  class  diagram  part  II 
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b.  ExplanationGet 


Figure  43.  ExplanationGet  class  diagram  part  I 

Figures  43  through  46  display  ExplanationGet.  ExplanationGet 
implements  the  ExplanationGetPortType  and  is  dependent  on  the  request  message  of  type 
ExplanatioGetRequestMsg.  Similar  to  StatusReport  the  same  Metadata  that  comes  in  the 
message  is  returned  to  the  client  along  with  the  Payload.  The  Payload  refers  to  an 
ExplanationRetumBundle  class  that  contains  a  Payload  and  Metadata.  The  Payload  is 
actually  a  list  of  assertions,  which  are  instances  of  the  Kb  Assertion  class.  Kb  Assertion 
has  two  components  called  AssertionMetadata  and  AssertionContext.  AssertionMetadata 
calls  the  DataBase  class  directly  while  AssertionContext  refers  to  DataSource. 
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Kb  Assertion  also  refers  to  KbClaim,  KbSupport,  and  KbEvidence  shown  on  Figure  45. 
Each  of  these  classes  either  contain  instances  of  classes  that  call  the  DataBase  class  or 
call  the  DataBase  class  directly  in  order  to  obtain  the  assertion  referenced  by  the  assertion 
ID  used  in  Payload. 
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Figure  44.  ExplanationGet  class  diagram  part  II 
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Figure  45.  ExplanationGet  class  diagram  part  III 
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Figure  46.  ExplanationGet  class  diagram  part  IV 
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c.  Kb  Up  date 


Figure  47.  KbUpdate  class  diagram  part  I 


Figure  47  above  shows  the  first  half  of  the  KbUpdate  client  class  diagram. 
Our  request  message  contains  Metadata  and  Payload.  The  Payload  holds  a  bundle 
depending  on  the  operation  desired.  Each  of  the  bundle  classes  have  their  own 
components  that  continue  in  Figure  48.  The  AssertionAddBundle  and 
AssertionReplaceBundle  eventually  use  the  same  class  path  structure  to  obtain  the 
assertion  data  as  the  ExplanationGet  service.  AssertionDeleteBundle  only  has  one  class 
that  handles  the  list  of  assertion  IDs  to  be  removed  from  the  external  database. 
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Figure  48.  KbUpdate  class  diagram  part  II 


C.  WEB  TIER 

In  this  section  we  will  describe  the  design  of  the  WSDL  documents  for  our  client 
and  services.  We  employed  two  WSDL  fdes;  one  for  KbUpdate  called 
STEPPortTypes_12b.wsdl  and  another  for  both  ExplanationGet  and  StatusReport  called 
UMDServices_12b.wsdl.  We  did  this  because  our  prototype,  discussed  in  Chapter  V, 
consists  of  two  separate  applications;  one  for  the  Web  services  and  the  other  for  the  Web 
client.  The  WSDL  files  were  modified  and  renamed  from  the  documents  originally 
generated  as  stepGovServices_12.wsdl  and  stepPortTypes_12.wsdl  (Tong,  2009).  The 
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binding  and  service  sections  of  the  UMD  Services  WSDL  were  left  for  us  to  define  since 
they  pertained  to  our  network  protocol  details.  Sub-sections  1  and  2  show  the  main 
sections  of  the  WSDL  files. 

1.  UMD  Services 


<wsdl:types> 

<xs  schema> 

i  |  <xs:import  namespace- ’http://wwwiarpagov/SCIL/STEP_Schema"  schemaLocation="UMDSchema_12b  xsd"/> 
</xs  schema:* 

</wsdl:types> 

<wsdl:  message  name="ExplanationGetRequest"> 

|  <wsdl:part  name-'omnia"  element ="stepd:ExplanationGetRequestMsgPart"/> 

</wsdl:message> 

<wsdl  message  name="ExplanationGetResponse”> 

<wsdl:part  name-'omnia"  element=''stepd:ExplanationGetResponsel\/lsgPart7> 

</wsdl:message> 

<wsdl  message  name="StatusReportRequest"> 

<wsdl:part  name-'omnia"  element="stepd:StatusReportRequestMsgPart7> 

</wsdl:message> 

<wsdl  message  name="StatusReportResponse"> 

|  <wsdl:part  name-'omnia"  element=”stepd:StatusReportResponseMsgPart7> 

</wsdl:message> 


Figure  49.  UMD  services  WSDL  part  I 


Figure  49  above  shows  the  types  and  messages  sections.  The  Schema  document 
was  generated  separately  and  is  referred  to  in  the  types  section  by  name.  The  messages 
section  shows  the  part  name  'omnia'  to  represent  the  name  of  the  request  and  response 
messages  to  be  used  between  service  and  client.  Figure  50  shows  StatusReportPortType 
and  ExplanationGetPortType  as  the  portTypes  to  be  used  by  the  client.  The  message 
types  previously  defined  are  referenced  here  as  the  input  and  output  messages. 
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<wsdl:portType  name-'StatusReportPortType"> 

<wsdl:documentation>Core  service.  Hosted  at  the  Performer  site.</wsdl:documentation> 

<wsdl:operation  name-'StatusReport”> 

I  <wsdl:documentation>Request-Response  STEP  AppServer  requests  a  status  report  from  Performer  team  servjce.</wsdl:documentation> 
i  <wsdl:input  message-'steps:StatusReportRequest'7> 

1  <wsdl:output  message="steps:StatusReportResponse"/> 

</wsdl:operation> 

</wsdl:portType> 

<wsdl:portType  name="ExplanationGetPortType“> 

<wsdl:documentation>Optional  service.  Hosted  at  the  Performer  site.  </wsdl:documentation> 

<wsdl  operation  name="ExplanationGet"> 

j  <wsdl:documentation>Request-Response.  STEP  AppServer  requests  an  explanation  from  Performer  team  service.</wsdl:documentation> 
!  <wsdl:input  message="steps:ExplanationGetRequest"/> 

|  <wsdl:output  message="steps:ExplanationGetResponse’7> 

</wsdl:operation> 

</wsdl:portType> 


Figure  50.  UMD  services  WSDL  part  II 


<wsdl:binding  name="StatusReportSoapBinding"  type-'steps:StatusReportPortType"> 

]  <soap12  binding  style-’document"  transport- 'http://schemas.xmlsoap.org/soap/http7> 
<wsdl  operation  name="StatusReport"> 

<soap12:operation  soapAction="statusReport”  soapActionRequired="true"/> 

<wsdl  input> 

|  <soap12:body  use="literal”/> 

</wsdl:input> 

<wsdl  output> 

|  <soap12:body  use-'literal"/> 

</wsdl  output> 

I  </wsdl  operation> 

</wsdl  binding> 

<wsdl  binding  name="ExplanationGetSoapBinding"  type="steps:ExplanationGetPortType"> 
j  <soap12  binding  styte="document"  transport="http://schemas.xmlsoap.org/soap/http7> 
<wsdl: operation  name="ExplanationGet"> 

j  <soap12:operation  soapAction="explanationGet"  soapActionRequired="true'7> 

<wsdl  input> 

j  <soap12  body  use- 'literal'7> 

</wsdl:input> 

<wsdl  out  put  > 

!  <soap12:body  use-1  iterat"/> 

</wsdl:output> 

</wsdl.operation> 

</wsdl  binding> 

Figure  5 1 .  UMD  services  WSDL  part  III 
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Figure  51  shows  the  binding  between  the  service  interface  descriptions 
(StatusReportPortType  and  ExplanationGetPortType)  to  the  their  respective  service 
implementations  (StatusReport  and  ExplanationGet).  Note  that  we  are  using  SOAP  over 
HTTP. 


Finally,  Figure  52  shows  the  service  section  combining  the  previously  defined 
port  names  and  binding  names  to  our  network  address  creating  the  end-point. 

<wsdl  service  name="UMD_Service"> 

<wsdl  port  name-'StatusReport"  bmding="stepn  StatusReportSoapBinding"> 

I  <soap12  address  location- http://10. 3. 21. 97:8080/UMD/UMD_Service'7> 

</wsdl  port> 

<wsdl  port  name=’'ExplanationGet"  binding-  stepn  ExplanationGetSoapBinding’'> 

I  <soap12  address  location- kttp://10. 3. 21. 97:8080/UMD/UMD_Service'7> 

</wsdl:port> 

</wsdl  service> 


Figure  52.  UMD  services  WSDL  part  IV 


2.  UMD  Client 

Figure  53  shows  the  KbUpdate  WSDL.  Aside  from  the  name  changes  in  the 
messages,  ports,  and  binding  sections  that  reflect  the  KbUpdate  operation,  the  structure  of 
this  document  is  the  same  as  the  UMD  Services  WSDL.  The  service  section  provides  the 
combination  of  the  binding  and  port  names  and  also  specifies  the  network  address  of  the 
external  service. 
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<wsdl /types? 

<xsschema> 

<xs  import  namespace=Tittp:/ft)ww  arpa  goWSCIUSTEP_Schema"  schemaLocation='stepSchema_12bxsd7? 

</xs  schema? 

</wsdl  types? 

<\*sd!  message  name-'KbUpdaleRequest'? 

|  <wsd  part  n*m»*'omnia"  «4eme«l=‘stepd:KbUpdateRequestMsgPait7> 

</w$dl  message? 

<wsdl  message  name=‘Xbt)pd8teR«ponse'> 

|  <wsd  part  name=‘wmia"  eteme«il=‘siepd  KbUpdateResponseMsgPait7> 

<,'wsdl  message? 

<v*sdl  poitType  name='Xbl)pdatePortType’> 

<wsd  documentation>Cofe  service  Hosted  on  the  STEP  AppSeiver  </wsdl  documentation? 

<wsd  operation  name-'KWJpdate"? 

<wsdl  documentation?Request-Response  Pertwmer  team  service  pushes  assertions  to  STEP  AppSener  <Awsd  documentation? 
cwsdl  input  messages'steps  KbOpdateRequest’V? 

<wsdl  output  message="steps  KbOpditeResponseV? 

</wsd!  operation? 

</wsdl  portType? 

<wsdl  import  namespace-tiltp  i/www  iarpa  gov/SQL/STEP_PortTypes“  location^' stepPortTypes_12b.wsdl7? 

<\»sdl  binding  name="KbUpdateSoap6inding~  type='stepe  KbUpdatePortType'? 

<soap12  binding  style- 'document"  transport ="bttp//schemas  xmlsoap  org'soap’http'f? 

<wsdl  operation  name^TKbUpdate*? 

<soap12  operation  soepActx)n«1<yjpd8te"  soapActionReguued=true7? 

<w$d.input> 

|  <soap12  body  use=Trteial7? 
xAesdlmput? 

<wsd  output? 

|  csoap12  body  use=1iteral7> 

</wsdl.outpU? 

</wsd  operation? 

</wsdl  bindng? 

<wsd!  service  name="StepAppServerService'> 

I  <wsdl  port  name="KbUpdate"  bmding=’stepn  KbUpdateSoapBinding"? 

<soap12  address  location- Tittp/riO  3  21  1  8084/STEP/StepAppServerSeivice7> 

<7wsdport> 

</wsdl  sennce? 

</Wsd  definitions? 


Figure  53.  UMD  client  WSDL 


D.  PRESENTATION  TIER 

We  now  shift  our  focus  to  the  presentation  tier,  which  contains  the  components 
that  create  and  execute  the  UI  necessary  for  our  users  to  communicate  with  the  other  tiers 
in  the  system. 

Based  on  the  requirements  from  Chapter  III,  a  closed  Web  application  is 
necessary  to  implement  the  UI.  Using  a  closed  Web  application  to  serve  as  our  UI  means 
that  only  our  users  will  be  presented  with  the  Web  pages  to  interface  with  and  execute  the 
system  functionality;  similar  to  how  a  person  would  use  the  Internet  to  manage  his/her 
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personal  online  banking  account.  The  UMD  performer  team  users  will  perform  the 
system  operations  by  using  the  Web  pages  to  interface  with  the  local  system’s  business 
logic  through  an  HTTP  connection.  The  interaction  is  initiated  with  a  request  for  a  Web 
page  by  the  user’s  Web  browser.  The  local  system’s  Web  server  will  return  the  requested 
Web  pages  to  the  users  for  execution.  The  File  system  manages  the  HTML  files  for  the 
Web  server  and  the  Application  server  executes  the  server-side  business  logic  (Conallen, 
2003).  Figure  54  shows  the  interplay  among  the  components. 


Page 
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Web 
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■upo 

File  System 

External 

Systems 


Figure  54.  Web  architecture  (From  Booch,  2001) 


The  remainder  of  this  section  is  separated  into  two  sections.  In  Section  1,  we  used 
the  Microsoft  PowerPoint  2007®  application  to  develop  a  conceptual  design  of  the  UI 
Web  pages.  We  also  discuss  the  intended  functionality  behind  each  Web  page  and  step 
through  what  a  user  would  encounter  while  using  the  Web  application.  Section  2  shows 
the  respective  Web  pages’  UML  class  diagrams. 

1.  UI  Web  Pages 

We  begin  our  design  of  the  UI  with  another  UML  modeling  tool  called  an 
Activity  Diagram.  This  diagram  displays  the  workflow  associated  with  our  UI.  As 
depicted  in  Figure  55,  the  basic  structure  of  the  UI  allows  a  user  to  sign  in  and  view  the 
main  menu.  The  main  menu  provides  the  user  an  option  to  perform  one  of  several  system 
operations.  Finally,  the  user  can  sign  out  of  the  system  when  complete. 
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Figure  55.  UI  workflow 


a.  Sign  In 

The  first  step  for  our  users  would  be  to  sign  into  our  system  through  a  sign 
in  page  that  requires  the  user  to  input  a  username  and  password.  Figure  56  displays  our 
proposed  design  of  what  that  page  would  look  like. 
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SOCIO-CULTURAL  CONTENT  IN  LANGUAGE 

UMD  Performer  Team 

User  ID 

Password 

Sign  In  Cancel 

Figure  56.  Sign-in  Web  page 


b.  Main  Menu 

Figure  57  represents  a  preliminary  design  of  the  main  menu,  which  is 
displayed  following  user  authentication.  The  main  menu  will  display  the  status  of  the 
core  system  capabilities,  show  the  ten  most  recent  activities,  provide  the  user  a  means  to 
exit  the  system,  and  provide  the  user  hyperlinks  to  navigate  to  the  desired  Web  pages  to 
perform  the  system  functions.  For  clarity  purposes,  we  designed  the  main  menu  image  to 
show  only  four  activities  instead  of  ten.  A  DTG  is  associated  with  the  activity.  The  newer 
and  older  buttons  under  the  recent  activity  will  allow  the  user  to  view  additional  activity 
not  displayed.  A  color-labeled  display  on  the  top  right  corner  shows  the  current  state  of 
the  core  capabilities.  The  buttons  in  yellow  serve  as  hyperlinks  to  the  Web  pages. 
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Figure  57.  Main  menu  Web  page 
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c.  Store  Assertion 

If  the  user  wishes  to  store  an  assertion  that  has  not  been  previously  stored 
into  the  local  database,  the  user  would  select  the  Store  assertion  tab.  The  application 
would  then  provide  the  user  a  Web  interface  to  input  the  assertion  data.  For 
demonstration  purposes,  we  provide  two  pages  shown  in  Figures  58  and  59.  However,  the 
data  could  be  input  by  using  just  one  Web  page.  When  complete,  the  user  is  given  one  of 
three  store  options  to  execute: 

•  Store — Stores  the  assertion  in  the  local  database  only. 

•  Store  and  Transfer — Stores  the  assertion  in  the  local  database  and  then 
executes  the  KbUpdate  client  to  add  that  assertion  to  the  external  database. 

•  Store  and  Replace — Stores  the  assertion  in  the  local  database  and  then 
executes  the  KbUpdate  client  to  transfer  that  new  assertion  over  to  the 
external  database  in  order  to  replace  an  existing  assertion. 
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Figure  58.  Store  assertion  I 
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Figure  59.  Store  assertion  II 
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When  the  user  selects  the  option  to  Store  and  Replace,  the  application 
would  display  the  Web  interface  depicted  in  Figure  60.  The  interface  allows  the  user  to 
search  for  the  assertion  by  using  one  of  two  search  options:  by  external  ID  or  author.  The 
output  of  the  search  would  be  displayed  in  a  form  that  allows  the  user  to  select  only  one 
assertion  that  is  currently  in  the  external  database.  Upon  selection,  a  short  summary  is 
displayed  for  the  user  to  view  before  replacement. 
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Figure  60.  Store  assertion  III 


d.  Transfer  Assertion 

The  Transfer  assertion  operation  will  execute  the  KbUpdate  client  for 
assertions  that  have  been  previously  stored  in  the  local  database  only.  Figure  61  shows, 
upon  selection,  that  the  application  will  provide  the  user  an  option  between  sending  an 
assertion  not  currently  in  the  external  database  or  to  transfer  an  assertion  meant  to  replace 
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an  existing  one.  Figure  62  shows  the  interface  upon  selection  of  the  Send  a  new  assertion 
option.  The  user  is  provided  a  means  to  search  for  and  to  select  the  assertion(s)  to  be 
transferred.  If  the  user  selects  the  option  to  Replace  an  existing  assertion  the  user  will 
first  choose  the  assertion  that  will  do  the  replacing  using  a  Web  page  similar  to  Figure  62. 
The  user  will  then  select  the  assertion  to  be  replaced  through  a  Web  page  that  looks 
similar  to  Figure  60. 


Choose  one: 
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%  Send  a  new  assertion 


Continue  Cancel 


Figure  6 1 .  Transfer  assertion  I 
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Figure  62.  Transfer  assertion  II 


e.  Edit  Assertion  Data 

The  Web  interface  under  the  Edit  assertion  operation  will  allow  the  user  to 
select  an  assertion  based  on  a  search  for  either  the  author  or  the  assertion  local  ID.  The 
user  would  then  have  the  option  to  either  edit  or  delete  the  selected  assertion. 

After  a  user  selects  an  assertion  and  chooses  the  option  to  edit,  an  interface 
capable  of  being  edited,  similar  to  Figures  58  and  59  above,  will  appear  with  the  text 
fields  populated  with  the  current  assertion  data.  The  user  could  change  the  data  in  the  text 
fields  and  save  the  new  data.  If  an  external  ID  was  associated  with  the  assertion  selected 
for  editing,  then  the  KbUpdate  client  will  execute  and  replace  the  assertion  in  the  external 
database  with  the  newly  modified  version;  otherwise  the  newly  edited  assertion  will  be 
stored  locally  with  the  same  local  ID.  Figure  63  displays  the  Edit  Assertion  Web 
interface. 
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If  the  user  selects  the  delete  option,  and  there  is  not  an  external  ID 
associated  with  the  assertion,  then  the  assertion  will  only  be  removed  from  the  local 
database.  However,  if  there  is  an  external  ID  associated  with  the  assertion  to  be  deleted, 
the  user  will  receive  a  prompt,  as  depicted  in  Figure  64,  to  decide  between  deleting  an 
assertion  from  the  external  database  only,  or  deleting  the  assertion  from  both  the  local 
and  external  databases.  In  either  case,  the  external  ID  for  that  assertion  will  no  longer  be 
recognized  by  the  external  system,  and  will  be  removed  from  the  local  database.  The  user 
can  also  select  the  help  button  to  understand  the  ramifications  of  his/her  decision.  In 
either  case,  the  KbUpdate  client  will  be  executed  to  delete  the  respective  assertion 
referred  to  by  the  external  ID. 


lalii  Assertion 


Search  for  the  assertion  to  be  edited  by 


Local  ID 


Search 


Author 


Search 


Select  I  lie  assertion  to  be  edited: 


■ 

External  ID 

I.ocallD 

Author 

DTG 

1 

At  2567 

3 

Thomas  Jones 

20 10-01-05TI  7:00:00  -0.5:00 

a 

A123BTR 

16 

Robert  Ueeker 

2010-01-10T1 8:00:00-05:00 

□ 

1365QGX 

12 

Gladys  Knight 

20 10 -OMJTl  5>:00.00 -05:00 

a 

C567QX 

8 

Frederick  Fender 

2010-01-0m0:00:00 -05:00 

Edit  Delete 


Main 

Menu 


Figure  63.  Edit  assertion 
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Choose  one: 

%  Delete  from  external  database  only 
%  Delete  from  both  databases 

Delete  Back  Help 

Figure  64.  Edit  assertion  II 


e.  Set  Capability  Status 

The  Set  Capability  Status  operation  will  only  allow  an  administrator  to  set 
the  capability  status.  If  a  non-privileged  user  would  attempt  to  access  this  operation,  the 
application  would  generate  a  message  for  the  user  stating  that  the  user  does  not  have 
those  privileges.  The  Web  interface  will  show  the  administrator  three  sets  of  radio 
buttons  per  capability.  The  administrator  would  select  the  appropriate  status  per 
respective  capability,  and  then  save  the  operation  (see  Figure  65). 
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Select  (lit-  capability  status 

•  Available 

KbUpDATE  •Unavailable 

•  Unsupported 


•  Av  aiiablc 

DATAPUSH  •  Unavailable 

•  Unsupported 


•  Available 

Explan, \ttonGet  #  UlK,V!ulable 

•  I  n  supported 

Save  Cancel 


Figure  65.  Select  the  status 


f.  User  Accounts 

The  User  Accounts  operation  is  also  restricted  to  administrators  in  the 
same  way  as  setting  the  capability  statuses.  When  selected,  the  administrator  will  be 
given  the  option  (Figure  66),  to  either  create  account  or  to  modify  account. 

If  the  administrator  selects  the  option  to  create  account,  the  application 
will  display  an  interface  with  text  fields  for  entering  the  user’s  personal  data.  When 
complete,  the  administrator  would  save  the  user  account  information,  thereby  storing  the 
data  in  the  local  database.  See  Figure  67. 

If  the  administrator  selects  the  option  to  modify  account,  a  Web  interface 
listing  all  of  the  users  will  be  shown.  The  administrator  would  select  the  user  account  to 
perform  either  a  modify  or  delete  function  (Figure  68).  If  modify  is  selected,  the 
administrator  will  be  presented  with  an  interface  capable  of  being  edited  (Figure  69),  but 
with  the  text  fields  populated  with  the  user’s  account  data.  The  administrator  can  make 
changes  as  necessary  and  save  the  changes,  thereby  updating  the  local  database.  If  the 
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administrator  selects  delete,  the  application  will  prompt  the  administrator  for 
confirmation.  After  confirmation,  the  user  account  data  will  be  permanently  removed 
from  the  local  database. 


Choose  one: 

%  Create  account 
%  Modify  account 

Continue  Cancel 


Figure  66.  User  account  I 


('rcat«'  Account 


(Serve*  a?  the  U*et  ID) 


Create  Cancel 


Figure  67.  User  account  II 
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lloilih  Arronnl 


■ 

Last  Name 

First  Name 

User  ID 

Thomas 

Jones 

jTbomas@myEmail.com 

i 

Robert 

l.’eckor 

rUecker@myEmail.com 

□ 

Gladys 

Knight 

gKnight@myEmail.com 

Frederick 

Fender 

fFender@myEmall.com 

Delete 

Modify 

Cancel 

Figure  68.  Modify  account 


Arrouut 


Flirt  name  Thomas 

Last  name 


Jones 


Email 


Password 


jThoniasa  myKmail.com 


(Server  as  voui  User  ID  i 


password 


Re-type  Password  password 


Update  Cancel 


Figure  69.  Update  account 


2.  UI  Class  Diagrams. 

We  now  present  the  models  of  the  UI  Web  application  using  UML  class 
diagrams.  It  is  important  to  note  that  the  original  UML  standard  notations  were  never 

intended  to  represent  Web  pages.  It  was  not  until  the  Web  Application  Extension  (WAE) 
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for  UML  was  adopted  that  Web  pages  were  capable  of  being  represented  by  new 
modeling  notations.  Jim  Conallen,  co-founder  of  UML,  states  that  the  extension  to  UML 
is  expressed  using  the  following  mechanisms:  stereotypes,  tagged  values,  and  constraints 
(Conallen,  Modeling  Web  Application  Architectures  with  UML,  1999).  In  his  book, 
Building  Web  Applications  With  UML  Second  Edition,  Conallen  describes  these 
mechanisms  as  follows: 

Stereotype,  an  extension  to  the  vocabulary  of  the  language,  allows  us  to 
attach  a  new  semantic  meaning  to  a  model  element.  Stereotypes  can  be 
applied  to  nearly  every  model  element  and  are  usually  represented  as  a 
string  between  a  pair  of  guillemets:  «  ».  However,  they  can  also  be 
rendered  by  a  new  icon. 

Tagged  value,  an  extension  to  the  property  of  a  model  element,  is  the 
definition  of  a  new  property  that  can  be  associated  with  a  model  element. 

Most  model  elements  have  properties  associated  with  them.  Classes,  for 
instance,  have  names,  visibility,  persistence,  and  other  attributes 
associated  with  them.  A  tagged  value  is  rendered  on  a  diagram  as  a  string 
enclosed  by  brackets. 

Constraint,  an  extension  to  the  semantics  of  the  language,  specifies  the 
conditions  under  which  the  model  can  be  considered  well  formed.  A 
constraint  is  a  rule  that  defines  how  the  model  can  be  put  together. 
Constraints  are  rendered  as  strings  between  a  pair  of  braces:  {}. 

Conallen  defines  three  core  class  stereotypes:  Server  page,  Client  page,  and 
HTML  form;  all  three  of  which  comprise  the  aforementioned  mechanisms.  These  classes, 
and  the  stereotype  class  associations  described  in  Table  9,  were  used  to  design  the  class 
diagrams  in  the  following  pages.  Figure  70  shows  the  WAE  class  diagram  for  the  main 
menu. 
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Table  9.  Stereotyped  associations  (From  Conallen,  2003) 


Figure  70.  Main  menu 
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From  the  main  menu,  the  user  could  choose  among  the  five  operations.  Figure  71 
shows  the  interaction  between  the  classes  for  the  case  when  the  user  chooses  to  store  an 
assertion.  This  model  demonstrates  that  a  user  can  still  replace  a  current  assertion  in  the 
external  database  after  its  initial  creation  at  the  local  level.  As  per  the  requirements  in 
Chapter  III,  the  diagrams  depict  feedback  in  the  form  of  a  Web  page  after  the  successful 
completion  of  the  respective  operation. 


Figure  7 1 .  Store  assertion 


Figure  72  shows  the  user’s  choice  in  transferring  an  assertion  that  has  only  been 
stored  locally.  Again,  the  user  does  have  the  option  to  replace  an  assertion  currently  in 
the  external  database;  that  option  is  a  continued  in  Figure  73. 
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Figure  72.  Transfer  assertion 


Figure  73.  Transfer  assertion  II 
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Figure  74  shows  the  user’s  option  to  either  edit  or  delete  an  assertion  from  the 
databases.  The  form  DeleteForm  provides  the  user  another  option,  to  remove  the 
assertion  locally  only  or  from  the  external  database,  too. 


Figure  74.  Edit  assertion 


Setting  the  capability  status  requires  the  administrator  to  choose  from  one  of  three 
sets  of  radio  buttons  per  capability.  The  selected  button  is  represented  in  the  form 
DeleteForm.  See  Figure  75. 
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Figure  75.  Set  capability  statuses 


Finally,  the  administrator  is  given  the  option  either  to  create  a  new  user  or  modify 
an  existing  user  account.  See  Figure  76. 


Figure  76.  User  accounts 
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E.  SUMMARY 

In  this  chapter,  we  took  the  requirements  from  Chapter  III  and  used  them  to 
provide  the  readers  our  proposed  system  design.  We  began  our  design  with  the  Database 
tier,  wherein  we  summed  up  and  displayed  the  attributes,  entities,  and  relationships  of  the 
system  in  an  ER  diagram.  We  followed  up  by  using  an  algorithm  to  map  the  ER  diagram 
into  an  RDS,  which  we  will  use  to  create  our  database  tables.  Our  next  step  was  to  design 
the  Business  Logic  tier  by  presenting  aspects  of  our  XML  Schema  and  generating  the 
UML  class  diagrams  that  express  the  functionality  of  the  core  operations  of  our  system: 
the  StatusReport  WS,  the  KbUpdate  client,  and  the  ExplanationGet  WS.  For  our  Web 
tier,  we  presented  the  WSDL  documents  that  we  will  use  as  our  endpoints.  Finally,  for 
the  Presentation  tier,  we  showed  the  reader  our  design  for  the  Web  pages  to  be  used  by 
the  local  user  to  operate  the  system,  followed  by  the  Web  application  UML  class 
diagrams.  In  Chapter  V,  we  present  our  prototype  of  the  system  to  be  used  by  the  UMD 
performer  team. 
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V.  PROTOTYPE 


In  Chapter  I,  we  described  the  basic  system  features  that  the  UMD  performer 
team  would  need  in  order  to  contribute  to  the  SCIL  program.  The  first  focused  on  the 
local  user’s  management  of  the  assertion  data  that  would  allow  for  the  collection,  storage, 
and  modification  of  the  assertion  prior  to  distribution.  The  second  was  to  allow  for 
remote  access  to  the  data.  This  ability  is  realized  with  the  use  of  our  core  Web  services 
described  in  Chapter  III  (StatusReportWS  and  ExplanationGetWS).  The  third  feature  was 
the  ability  to  transfer  the  data  to  the  external  knowledge  repository  over  the  Internet.  Our 
Web  service  client,  KbUpdate,  has  been  designed  to  manage  the  transfer  of  assertion  data 
to  the  external  database;  this  includes  the  ability  to  replace  and  delete  assertion  data. 

In  this  chapter,  we  will  describe  the  prototype  of  the  system.  Our  prototype 
consists  of  a  database  store  that  supports  our  two  core  Web  services  (StatusReportWS 
and  ExplanationGetWS),  and  our  Web  service  client  (KbUpdate).  The  prototype  also 
involves  the  application  server  in  which  the  Web  services  are  deployed.  Our  objective  for 
this  prototype  was  two-fold.  First,  we  wanted  to  provide  a  proof  of  concept 
implementation  for  both  Web  services  and  WS  client  in  support  of  the  preliminary 
engineering  tests.  Second,  we  wanted  to  provide  the  stakeholders  with  a  working  system 
capable  of  being  modified  and  upgraded  for  their  future  use. 

Our  system  was  developed  in  an  Apple®  Macintosh  desktop  computer  running 
OS  X.  This  chapter  begins  with  the  implementation  of  our  local  database.  We  will 
describe  the  database  tables  we  developed  to  interact  with  the  business  logic  of  our 
system.  Next,  we  present  our  Web  services  followed  by  our  client.  Using  screenshots  of 
the  applications,  we  will  walk  the  reader  through  the  sequence  of  events  that  transpire  in 
order  to  execute  each  operation. 

A.  MYSQL  DATABASE 

Although  the  SRS  in  Chapter  III  described  the  DBMS  to  be  a  Relational-type,  we 
also  researched  into  the  feasibility  of  using  an  Object-Oriented  Database  Management 
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System  instead.  In  the  end,  we  selected  the  MySQL  Community  Server  version  5.1.49 
DBMS  (www.mysql.com)  for  our  prototype  because  the  database  is,  at  this  point  in  time, 
required  to  handle  only  simple  data  types  (i.e.,  numbers  and  strings).  This  edition  of  the 
MySQL  DBMS  is  also  open-sourced,  and  is  compatible  with  the  NetBeans  Integrated 
Development  Environment  (IDE),  which  we  used  to  develop  our  applications.  Based 
on  the  RDS  we  designed  in  Chapter  IV,  we  constructed  a  total  of  six  tables  to  support 
our  system  operations:  status,  assertionData,  claimTarget,  contextDataSegment, 
evidenceStatements,  and  supportTechTerm. 

1.  Status 

Figure  77  displays  a  description  of  the  status  table  that  we  generated  using  SQL. 
The  Field  column  on  the  left  holds  the  names  of  the  columns  in  the  table.  The  status  table 
is  queried  for  all  six  values  whenever  the  StatusReportWS  is  consumed  by  the  external 
client.  The  DTG  columns  are  separately  updated  with  the  successful  execution  of  either 
the  KbUpdate  or  DataPush  clients  or  when  the  ExplanationGetWS  has  been  consumed. 


nysql>  describe  status; 


Field 

-+ - 

1  Type 

-+ - 

1  Null 

1 

- + - 

Key  1  Default 

-+ - 

1  Extra 

kbu_status 

1  varchar(25) 

1  NO 

1 

1  NULL 

1 

dp_status 

1  varchar(25) 

1  NO 

1 

1  NULL 

1 

eg_status 

1  varchar(25) 

1  NO 

1 

1  NULL 

1 

kbu_dtg 

1  datetime 

1  YES 

1 

1  NULL 

1 

dp_dtg 

1  datetime 

1  YES 

1 

1  NULL 

1 

eg_dtg 

1  datetime 

-+ - 

1  YES 

-+ - 

1 

"  +  • 

1  NULL 

- + - 

1 

-+ - 

&  raws  in  set  (0.00  sec) 


Figure  77.  MySQL  status  table 


2.  AssertionData 

Figure  78  represents  the  assertionData  table.  This  table  holds  all  of  the  assertions 
that  are  referenced  by  both  locallD  and  externallD.  However,  not  all  of  the  assertion  data 
can  be  found  in  this  table.  We  needed  to  generate  four  other  tables  to  hold  the  remainder 
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of  the  data  because  those  tables  would  be  required  to  hold  at  least  one  row  of  data  per 
assertion.  To  handle  this  one-to-many  relationship,  we  created  a  foreign  key  called 
’locallD’  in  claimTarget,  evidenceStatements,  supportTechTenn  and  contextDataSegment 
that  referenced  locallD  from  assertionData.  This  relationship  allowed  for  the  entire 
assertion  data  to  be  inserted  into  and  read  from  our  database  tables.  Figure  79  shows  the 
four  additional  tables. 


Field 

1  Type 

1  Null 

1 

Key 

1 

Default  1  Extra 

locallD 

1  int(ll) 

1  NO 

1 

PRI 

1 

NULL  1  auto_increment 

dtg 

1  timestamp 

1  NO 

1 

1 

CURRENT_TIMESTAMP  1 

flag 

1  varchar(25) 

1  YES 

1 

1 

NULL  1 

externallD 

1  varchar(25) 

1  YES 

1 

1 

NULL  1 

display 

1  varchar(25) 

1  YES 

1 

1 

NULL  1 

strength 

1  float 

1  YES 

1 

1 

NULL  1 

version 

1  varchar(25) 

1  YES 

1 

1 

NULL  1 

theoretical_frame 

1  varchar(25) 

1  YES 

1 

1 

NULL  1 

predicate_name 

1  varchar(50) 

1  YES 

1 

1 

NULL  1 

speaker_type 

I  varchar(25) 

1  YES 

1 

1 

NULL  1 

speaker_id 

1  int(ll) 

1  YES 

1 

1 

NULL  1 

tgtAttributeType 

1  varchar(25) 

1  YES 

1 

1 

NULL  1 

lang_use_dom 

1  varchar(50) 

1  YES 

1 

1 

NULL  i 

sourceName 

1  varchar(45) 

1  YES 

1 

1 

NULL  1 

sourceLocation 

1  varchar(45) 

1  YES 

1 

1 

NULL  1 

sourceLanguage 

1  varchar(45) 

1  YES 

1 

1 

NULL  1 

sourceType 

1  varchar(45) 

1  YES 

1 

1 

NULL  1 

sourceMedium 

1  varchar(45) 

+ - 

1  YES 

■  + - 

1 

1 

-+ 

NULL  1 

- + - 

Figure  78.  MySQL  assertionData  table 
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mysql>  describe  claimTarget; 

+ - + - + - + - + - + - + 

I  Field  I  Type  I  Null  I  Key  I  Default  I  Extra  I 

+ - + - + - + - + - + - + 

I  externallD  I  varchar(25)  I  YES  I  I  NULL  I  I 

I  locallD  I  varchar(50)  I  YES  I  MUL  I  NULL  I  I 

I  tgt_type  I  varchar(S0)  I  YES  I  I  NULL  I  I 

I  tgt_entity_id  I  int(U)  I  YES  I  I  NULL  I  I 

+ - + - + - + - + - + - + 

4  rows  in  set  (0.00  sec) 

mysql>  describe  evidenceStatements; 


1  Field 

1  Type 

1  Null 

1  Key  1  Default 

1 

Extra  1 

1  externallD 

1  varchar(25) 

1  YES 

1  1  NULL 

1 

1 

1  locallD 

1  varchar(50) 

1  YES 

1  MUL  1  NULL 

1 

1 

1  doc 

1  varchar(500) 

1  YES 

1  1  NULL 

1 

1 

1  start_line 

1  int(ll) 

1  YES 

1  1  NULL 

1 

1 

1  end_line 

1  int(ll) 

1  YES 

1  1  NULL 

1 

1 

1  tactic 

+ - 

1  varchar(50) 

-+ - 

1  YES 

-+ - 

1  1  NULL 

-+ - + - 

1 

1 

- + 

6  rows  in  set  (0.00  sec) 


mysql>  describe  supportTechTerm; 

+ - + - + - + - + - + - + 

I  Field  I  Type  I  Null  I  Key  I  Default  I  Extra  I 


+ - 

-+ - 

-  + - 

-  + - 

-+ - 

- + - 

- + 

1  externallD 

1  varchar(25) 

1  YES 

1 

1  NULL 

1 

1 

1  locallD 

1  varchar(50) 

1  YES 

1  MUL 

1  NULL 

1 

1 

1  gloss 

1  varchar(2500) 

1  YES 

1 

1  NULL 

1 

1 

1  term 

1  varchar(S0) 

1  YES 

1 

1  NULL 

1 

1 

1  data_snippet 
+ - 

1  varchar(2500) 

-+ - 

1  YES 

-+ - 

1 

-+ - 

1  NULL 

-+ - 

1 

- + - 

1 

- + 

5  rows  in  set  (0.01  sec) 


mysql>  describe  contextDataSegment ; 

+ - + - + - + - + - + - + 

I  Field  I  Type  I  Null  I  Key  I  Default  I  Extra  I 

+ - + - + - + - + - + - + 

I  externallD  I  varchar(25)  I  YES  I  I  NULL  I  I 

I  locallD  I  varchar(50)  I  YES  I  MUL  I  NULL  I  I 

I  d_segment  I  varchar(2000)  I  YES  I  I  NULL  I  I 

+ - + - + - + - + - + - + 

3  rows  in  set  (0.00  sec) 


Figure  79.  MySQL  assertion-related  tables 


B.  UMD  OPERATIONS 

Now  that  the  reader  has  seen  our  underlying  data  store,  let  us  turn  to  the  execution 
of  the  three  core  prototype  operations.  We  designed  our  applications  with  the  NetBeans 
IDE  version  6.8,  an  open-source  application  development  tool,  using  the  Java™ 
Development  Kit  6  update  20.  Both  Web  services  were  developed  under  one  Java  Web 
application  project,  entitled  UMD,  and  subsequently  deployed  to  the  open-source 
Glassfish  Web  application  server  version  3.  The  program  required  to  manage  the 
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assertion  data  and  the  capability  status  was  developed  using  the  Java  Standard  Edition 
application  called  NPS  SCIL.  A  rudimentary  command  line  UI  supported  by  Java  Swing 
GUI  components  were  developed  to  assist  the  local  user  in  running  the  program — the 
ideal  UI  being  the  Web  application  designed  in  Chapter  IV. 

1.  StatusReport 

a.  Setting  the  Status 

A  local  user  can  execute  the  NPS  SCIL  application  by  running  the 
NPS  SCIL.jar  fde  created  from  the  compiling  process.  As  displayed  in  Figure  80,  upon 
execution,  the  user  is  presented  with  a  set  of  options.  Selecting  the  'update'  command  will 
generate  a  window  for  the  user  to  select  the  appropriate  status  per  capability.  When 
finished,  the  user  clicks  on  the  'Okay'  button  that  executes  an  excerpt  of  the  Java  code 
displayed  in  Figure  81,  which  calls  the  method  named  writeCapabilityStatus(),  displayed 
in  Figure  82,  to  insert  the  desired  status  values  into  the  database  table  status  shown  in 
Figure  83. 


To  irodify  an  assertion  frow  external  Knowledge  Bose,  type  the  word:  'irodify1. 

To  quit  type:  'quit' . 

quit 

church:-  cnartclll  javo  jar  "/Users/cirarteU/Dciwnloods/)'PS_SCIl /dist/ld^.SCII  .}or* 
To  stone  a  new  Assertion,  type  the  word:  'store1. 

To  update  the  status  of  our  core  capabilities,  type  the  word:  'update'. 

To  rrndify  an  assertion  frnw  external  Knowledge  Bose,  type  the  word:  'nwdify'. 

To  quit  type:  'quit'. 


church:-  cnartellS  java  -jar  "/Users/crartell/Downloods/NPS.SQL/dist/HPS.SCIL.jor* 
To  sto*e  a  new  Assertion,  type  the  word:  'store1. 

To  update  the  status  of  our  core  capabilities,  type  the  word:  'update1. 

To  trodify  an  assertion  4 row  external  Knowledge  Base,  type  the  word:  ‘ftodlfy*. 

To  quit  type:  'quit*. 


update 


User  enters  ‘update' which  generates  the  UI. 


BOO 

KbUp4«t» 


Suiu*  Srlirtlor 


© 

O' 


(  Ofcjy  }  f  C«i»l  ) 


Figure  80.  Executing  NPS_SCIL.jar 


111 


if  ORsiiiSutcorH  .is5elected() )  < 
dpStatus  =  ("Va:  a  1-.  •?*'); 
l  else  if  (jRadioBjttonS.isSelectedO)  1 
dpStatus  =  ("'Jnava:  latle  ); 

}  else  < 

dpStatus  -  ( "'Jr.  ■  -pc.  _ ;  tec  ) ; 

> 

if  (jRadi:Sutton7.is5elected() )  ( 
egStatus  =  ("Available"); 

)  else  if  (jF.sdio3uttor.S.isSelected|) )  { 
egStatus  ■  ("Unavailable”); 

)  else  < 

egStatus  =  ("Unsupported"); 

)  try  ( 

DatabaseConnection  con  »  new  DatabaseConnection  () ; 
con.writeCapabilityStatus (kbuStatus,  dpStatus,  egStatus); 
JOptionPane.sAcvyessageSialoglnull,  "  The  status  has  beei  puiteii."); 

System. exit (0) ; 

Figure  8 1 .  Method  call  to  write  the  statuses 


public  void  writeCapabi 11 tyStatus (String  icb,  String  dp.  String  eg)  throws  Exception  { 

String  sqlStmtl  “  "UPDATE  status  SET  ktu_status  -  '".concat()tb)+"',  "  + 
"ipstatus  -  ' " . concat (dp) +" ' ,  ec_statu;  -  ' " . concat (eg) +" ' 

try  { 

Class. forifanretdrivexName)  ; 

con  =  DriverManager . getCoimection (rJRi,  CSERN'AKE,  PASSWORD); 
stitti  =  ccn.prepareStateaner.t  (sqlStnstl)  ; 

.  . executeUpdate  () ; 

>  catch  (SOLExceptlon  e)  ( 

e .printStackTrace () ; 

)  finally  { con. close (); ) 

> 

Figure  82.  Connection  to  the  database 


mysql>  select  kbu.status,  dp.status,  eg_status,  kbu_dtg,  dp_dtg,  eg_dtg  from  status; 

+ - + - + - + - + - + - + 

I  kbu.status  I  dp.status  I  eg_status  I  kbu_dtg  I  dp_dtg  I  eg_dtg  I 

+ - + - + - + - + - + - + 

I  Available  I  Unavailable  I  Available  I  2010-07-31  13:27:35  I  2010-07-31  11:37:44  I  2010-07-31  11:38:07  I 

+ . + . + . + . + . + . + 

Figure  83.  Status  table  after  execution 
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b.  The  Web  Service 

The  Web  application  can  be  executed  by  running  the  UMD.war  file 
generated  from  the  compiling  process.  Prior  to  deploying  the  WS  to  the  Glassfish  server, 
we  tested  it  by  using  the  open-source  software  called  soapUI  version  3.0.1 
(www.eviware.com).  This  software  allows  users  to  act  as  clients  and  consume  Web 
services  over  the  Internet.  This  was  important  to  us  because  we  needed  a  way  to 
determine  if  the  correct  data  was  returned  upon  a  query  from  the  external  client.  Figure 
84  shows  the  soapUI  split  screen  interaction  between  the  client’s  request  on  the  left  and 
the  StatusReportWS  response  on  the  right. 

Request  1 


►  +=  if  0  □  Q  it  •  |hnp://localhost:48394/UMD/UMD_Service~ 


<soap Envelope  xmlns:soap  ="http://www.w3.org/2003/05/soap-envelo 

- 

< 

> 

[^S  Envelope  xmlns  S  =  "http://www.w3.Org/2 00 3/0 5/soap -envelope"  > 

X 

1 

aL 

<soap:Header/> 

<soap:Body> 

<  step :  StatusRep  ortRe  que  stMsgP  art> 

<step:Metadata> 

<step:MessageId>  checkStatus  </step:MessageId> 

<  step  :Re  que  storId>  GOV  J^/step  Re  que  storId> 

</step:Metadata> 

</ step :  StatusRep  ortRe  que  stMsgP  art> 

</soap:Body> 

</soap:Envelope> 

X 

1 

a: 

<S:Body> 

<  StatusRep  ortRe  sponseMsgP  art  xmlns  ="http://www.iarpa.gov/SCIL/STEP_Schema"  > 
<Metadata> 

<MessageId>  checkStatus  </MessageId> 

<RequestorId>  GOV  </RequestorId> 

</Metadata> 

<Payload> 

<  StatusRetumBundle  > 

<Payload> 

<  StatusRep  ort> 

<KbUp  date  C  ap  ability  > 

<  State  >  available  </State> 

<LastDtg>  2010-07-31T13:27:35-08:00</LastDtg> 

</KbUp  date  Cap  ability> 

<DataPushCapability> 

<  State  >unavailable  </State> 

<LastDtg>  2010-07-31T1 1:37:44-08:00  </LastDtg> 

</D  ataPushC  ap  ability  > 

<ExplanationGetC  ap  ability  > 

<  State  >  available  </State> 

<LastDtg>  20 1 0-07 -3 1T1 1 :38:07-08:00  </LastDtg> 

</ExplanationGetC  ap  ability> 

</StatusReport> 

</Payload> 

</StatusRetumBundle  > 

</Payload> 

</StatusReportResponseMsgPart> 

</S:Body> 

</S:Envelope> 

Figure  84.  Testing  StatusReportWS 


Following  the  successful  test,  we  deployed  the  UMD.war  file  to  the 
Glassfish  server  to  be  consumed  by  the  external  client,  as  depicted  in  Figure  85. 
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Figure  85.  Deploying  UMD 


2.  KbUpdate  client 

In  this  section,  we  step  through  the  execution  of  the  KbUpdate  client.  The 
functionality  behind  the  options  to  either  add,  delete,  or  replace  was  discussed  in  detail  in 
the  two  previous  chapters.  In  this  section,  we  will  focus  on  the  ‘adding’  function  of  the 
client.  An  assertion  needs  to  be  in  the  local  database  before  the  update  so  we  will  begin 
with  storing  the  assertion. 

a.  Storing  the  assertion 

Figure  86  below  shows  the  execution  of  the  NPS  SCIL.jar  file  from  the 
command  line.  The  user  selects  the  option  to  'store.'  The  user  is  presented  with  an 
interactive  window  to  enter  the  assertion  data.  When  the  user  is  finished,  he  clicks  on  the 
'save'  button,  which  runs  the  code  that  executes  five  separate  SQL  statements  in  order  to 
store  the  assertion  data  into  its  respective  tables,  described  in  section  A. 2  above.  The 
system  generates  a  local  ID  for  the  assertion  and  inserts  that  ID  into  all  five  assertion- 
related  tables  in  the  same  row(s)  that  pertains  to  that  assertion.  Figure  87  shows  an 
excerpt  of  the  assertionData  table  that  highlights  the  local  ID  and  the  lack  of  an  external 
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ID  at  this  point  in  the  sequence.  Note  in  Figure  87  that  the  predicatename  and 
langusedom  columns  share  the  same  data;  this  is  because  the  data  entered  was  for  test 
purposes. 


User  executes  the  NPS_SCIL  « 

application  and  selects  the  option  >t 

to  ‘store’.  mi 


S  roni  in  zti  <8  M  IK) 


4 

I  P^r-sjaiviOrt 
i  Per'SJ.ovvon 
I  PcruMisiai 


lib 

|  UI  to  enter  assertion  data 

OMBHWT- 
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Figure  86.  Storing  an  assertion 


oysql>  select  local  ID,  dtg,  extemallD,  predicate_name,  speaker.id,  speaker  .type ,  lang_use_dan  from  assertionDota; 

+ - - ♦ - - - - - ► — - - - * - - - -♦ - +- — — — - - ► - - - - - + 

I  locallD  1  dtg  I  external ID  I  predicate_name  1  speakcr.id  I  spcakcr.typc  I  long_use.<lom  I 


2  I  2010-07-30  13:32:17  I  NULL 

3  I  2010-07-30  14:12:10  I  lM>5O083b8a 

6  I  2010-07-31  12:21:53  I  NULL 

7  I  2010-07-31  12:35:58  I  NULL 

8  I  2010-08-03  <*>  70  50  I  Mill 
9i_l  2010-08-03  09:43:S8CLNUlp 


I  Persuasion  Attempt  I  1 
l  Persuasion  Attempt  I  1701 
I  Persuasion  Attempt  I  1 
I  Persuasion  Attempt  I  1 
I  Persuasion  Attempt  I  123 
I  Persuasion  Attempt  I  123 


test 

1  Persuasion  Attempt 

person 

1  Persuasion  Attempt 

test 

1  Persuasion  Attempt 

test 

1  Persuasion  Attempt 

person 

1  Persuasion  Attempt 

person 

1  Persuasion  Attempt 

Figure  87.  Assertion  in  the  database 
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b.  Updating  the  External  Database 


From  the  command  line,  instead  of  selecting  'store,'  the  KbUpdate  client  is 
run  by  selecting  the  option  to  ‘modify.’  The  application  then  gives  the  user  the  option  to 
either  add,  delete,  or  replace.  The  user  selects  the  option  to  'add'  and  is  then  prompted  for 
a  message  ID  and  for  the  locallD  of  the  assertion  to  be  added.  When  the  user  submits  the 
locallD  to  be  transferred,  the  system  reads  the  respective  assertion  data  in  all  five 
assertion-related  tables  and  sends  the  data  to  the  external  system.  Figure  88  is  a 
screenshot  of  the  Web  page  generated  by  the  external  system’s  Web  server  called  the 
STEP  server,  which  displays  the  list  of  assertions  currently  in  the  external  database 
(Naval  Research  Laboratory,  2010).  For  this  demonstration,  the  listing  created  on  2010- 
08-03  refers  to  the  assertion  with  local  ID  #9.  Figure  89  is  a  screenshot  of  another  STEP 
server  generated  Web  page  that  shows  the  specific  ID  #9  assertion  elements  following 
the  successful  transfer  (Naval  Research  Laboratory,  2010).  The  external  system  generates 
and  returns  an  external  ID  that  refers  to  that  assertion,  and  the  local  system  writes 
that  external  ID  into  the  rows  of  the  five  tables  that  pertain  to  the  local  copy  of  the 
assertion  that  was  just  sent.  Figure  90  shows  two  of  the  five  tables  with  external  ID 
TJMDb39f431a.’ 
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Results  (Found  5  current  assertions) 


Language 

Use 

Team 

•  Created 

Language 

Source 

Type 

Visibility 

Pprsuasinn 

Attempt 

UMD 

2010-08-03 

English 

NRL34 

Blog 

Public 

Persuasion 

Attempt 

UMD 

2010-07-30 

English 

NPS/UMD 

Blog 

Public 

Persuasion 

Attempt 

UMD 

2010-05-25 

Spanish 

SourceName 

blog 

a 

Private 

Persuasion 

Attempt 

UMD 

2010-05-25 

English 

SourceName 

email 

Private 

Persuasion 

Attempt 

UMD 

2010-05-25 

Spanish 

SourceName 

blog 

a 

Private 

Figure  88.  External  Web  server 


117 


Assertion  UMDb39f431a 


Figure  89.  External  Web  server 


nysgl>  select  locollD.  dig,  ealernallO,  prediccle-we,  speaker.id.  speaker. t>pe,  larg_use.dcn  from  osseraonOato; 

♦ - - ♦ - ♦— - - ♦- - ♦— - — - -♦ 

I  local  ID  I  dtg  external  ID  I  predicate.ncm*  I  speoker.ld  I  Saeaker.type  I  larg_use_dcri  I 


2 

i  2013-07  30  13:32:17 

MULL 

1  Persuasion  Attempt  1 

1 1 

i  test 

1  Persuasion  Attempt  1 

3 

I  2019  6?  30  14:1?: 10 

,M)S90A3hSa 

1  Persuasion  Attempt  1 

1701  1 

i  person 

1  Persuasion  Attempt  1 

6 

010-07-31 12:21:53 

<11X1 

1  Persuasion  Attempt  1 

i 

test 

1  Persuasion  Attempt  1 

7 

1  2010-07-31  12:35:58 

MIU 

l  Persuasion  Attempt  l 

1  1 

test 

1  Persuasion  Attenpt  1 

a 

i  2013-O8-03  09.20:59 

^Jll1  1 

1  Persuasion  Attenpt  I 

123  1 

t  person 

1  Persuasion  Attempt  1 

9 

I  2010-08-03  89:43:5S< 

)  Persuasion  Attempt  1 

123  1 

person 

1  Persuasion  Attempt  1 

f  rows  in  set  (0.00  sec) 


nysql>  select  externollD,  locailD,  start-line,  end  line,  tactic  freer  evidencebtatewerts; 


1  external  ID 

1  locollD 

1  start 

.line  1 

end.lcne  1  tactic 

1 

1  MULL 

1  2 

1 

1 1 

2  1  test 

1  l«iS0883b8o 

1  3 

1 

15  1 

15  1  Rodifinition 

I 

I 

1  3 

i 

24  1 

24  I  Enaothy 

1  MJLL 

1  4 

1 

1  1 

1  I  test 

1  WJLL 

1  5 

1 

1  1 

2  1  test 

1  MJLL 

1  6 

1 

1  1 

2  1  test 

1  MULL 

1  7 

1 

1  1 

2  1  test 

- - - 

1 

2  1 

3  1  Erpothy 

<LLM0bJ9f431o 

>9 

1 

2  1 

3  I  Enjothy 

77rr . 

9  fXMS  Ut  set  (3.00  sec) 


Figure  90.  External  ID  in  the  database 
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3.  ExplanationGetWS 


b.  The  Web  Service 

Now  that  we  have  data  that  is  ready  to  be  retrieved,  we  test  the  WS  using 
the  soapUI  software,  as  shown  in  Figure  91.  The  key  component  to  the  request  is  the 
external  ID.  Using  the  external  ID,  the  local  system  retrieves  the  respective  assertion  data 
located  in  the  assertion-related  tables.  Finally,  with  the  successful  test  of  the 
ExplanationGetWS  using  soapUI,  we  deployed  the  .war  file  to  the  Glassfish  server  for  its 
subsequent  consumption  by  the  external  client,  as  shown  in  Figure  85. 


<soap Envelope  xmlns:soap  -'http://www.w3.org/2003/05/soap-em 
<soap:Header/> 

<soap:Body> 

<  step  :ExplanationGetRe  que  stMsgP  art> 

<step:Metadata> 

<  step  :Me  ssageld>  Get9  </ step  :Me  s  s  ageld> 

<  step  :Re  que  storId>  GOV  </step:RequestorId> 
</step:Metadata> 

<step:Payload> 

<  step  :ExplanationRe  que  stBundle  > 

<step:Metadata> 

<step  :AssertionId-:  UMDb39f43 1  a  [:/step:AssertionId> 
</step:Metadata> 

</step  :ExplanationRe  que  stBundle  > 

</step:Payload> 

</step  :ExplanationGetRe  que  stMsgP  art> 

</soap:Body> 

</soap:Envelope> 


a 


■4a. 


Rs 


<AssertionEvidence> 

<Evidence Value >  Future  Evidence  value  </Evidence Value > 

<Evidenc  e  Statement> 

<  C  onstituentMultis  et> 

<P  ersuasionT  actic  > 

<tactic> Empathy  </tactic> 

<startlme>  2</startline> 

<  endlme  >  3</endline> 

<doc>blogspot.com_stormpetrel_20050326205100_ARB_20050 

</PersuasionTactic> 

</C  onstituentMultis  et> 

</Evidence  Statement 
</AssertionEvidence> 

<  As  s  ertionSupp  ort> 

<TheoreticalFrame>  This  interaction  includes  use  of  a  redefinition  tactic  a 
persuasive  force  of  the  redefinition  tactic  comes  in  its  ability  tomarshal  pre-existing 
beliefs  about  the  categories  its  linked  to.  This  isessentially  a  way  to  reframe  a  situation, 
often  in  subtle  ways.  Empathy  grows  out  of  Cialdini's  particular  category  Liking,  which 
states  thatwe  tend  to  be  convinced  by  those  we  like  or  admire.  </TheoreticalFrame> 
<TechnicalTerm  term-'redefinition"  > 

<TechnicalTermGloss>  Redefinition  is  an  agent's  attempt  to  reframe  thi 
that  something  bears  a  certain  property  (Predications)or  b)  analogizing  it  to 
something  else  (Analogy).  </TechnicalTermGloss> 

<DataSnippet>  "I  have  heard  with  great  sorrow  that  some  of  our  brethr 
killed  while  expressing  their  opposition  to  the  aggression  of  the  forces  of  the 
crusader  America  and  its  allies  against  the  Muslims'  territories  in  Pakistan  and 
Afghanistan. "  </DataSmppet> 

</Te  chnic  alT  erm> 

</As  s  ertionSupp  ort> 

</Assertion> 

</Payload> 


F igure  91.  T esting  ExplanationGetW S 


C.  USER  FEEDBACK 

With  the  operating  prototype  in  hand,  we  obtained  an  acceptance  test  by  a  UMD 

representative.  We  had  the  representative  step  through  the  following  sequence  of 
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operations:  setting  the  capability  status,  storing  a  new  assertion,  transferring  an  assertion, 
replacing  an  assertion,  and  deleting  an  assertion.  The  StatusReport  WS  and  all  three 
functions  of  the  KbUpdate  were  fielded  in  order  to  assist  in  the  completion  of  a  series  of 
engineering  tests  with  the  external  system.  Knowing  that  not  all  of  the  desired  features 
were  implemented  in  the  prototype,  the  representative  was  satisfied  with  the  prototype 
because  it  accomplished  its  intended  purpose,  and  it  allowed  for  future  modifications  as 
necessary. 

At  this  point,  the  system  has  been  used  in  multiple  engineering  tests  following 
directed  changes  to  the  XSD  by  both  IARPA  and  UMD.  An  agreed-upon  structure  of  an 
assertion  is  still  under  discussion  by  the  UMD  stakeholders,  so  actual  assertions  have  yet 
to  be  generated  and  forwarded  to  the  external  database. 

D.  SUMMARY 

In  this  chapter,  we  used  the  system  design  discussed  in  Chapter  IV  to  develop  our 
proposed  prototype  automated  system  to  manage  the  assertion  data  generated  by  the 
UMD  performer  team.  The  prototype  provides  a  means  for  the  stakeholders  to  validate 
the  system  design  and  a  working  platform  for  follow-on  research  and  development. 

We  used  the  MySQL  server  as  our  database  and  created  six  tables  to  store  the  data 
necessary  to  execute  the  core  operations.  Our  Web  client  application  provides  multiple 
functions  including: 

•  the  ability  to  add,  replace,  or  delete  assertions 

•  the  ability  to  store  an  assertion  into  the  database 

•  the  ability  to  set  the  capability  statuses 

We  also  provided  screenshots  of  the  assertion  as  displayed  in  the  external  STEP 
application  server.  Both  of  our  Web  services  and  our  Web  client  were  developed  using 
the  Java  programming  language.  We  demonstrated  to  the  reader  the  WS  testing  results 
using  the  soapUI  software.  Finally,  we  deployed  our  Web  services  to  the  Glassfish 
application  server  in  order  to  await  future  external  client  requests. 
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VI.  CONCLUSION 


A.  SYNOPSIS 

The  goal  for  this  thesis  was  to  design  and  develop  an  automated  system  to  be  used 
by  the  UMD  performer  team  in  support  of  the  SCIL  program  led  by  IARPA.  The  SCIL 
program  seeks  to  investigate  various  methodologies  to  help  understand  the  social  goals  of 
people  by  demonstrating  a  relationship  between  these  goals  and  their  particular  language 
use.  UMD’s  role  in  the  program  is  to  identify  the  social  goals  that  pertain  to  persuasion 
by  analyzing  chat-based  Web  forums.  The  end  product  of  the  analysis  of  the  unstructured 
text  is  a  set  of  assertions  that  declare  acts  of  persuasion  were  attempted. 

The  system  we  designed  enables  users  to  locally  store,  manage,  and  transfer  the 
assertions  to  the  external  system.  Eventually,  SCIL  will  be  combined  with  a  functionality 
that  uses  artificial  intelligence  techniques  to  process  raw  text.  The  processing  will  result 
in  assertions  that  are  then  forwarded  to  an  external  knowledge  base  run  by  IARPA. 

In  Chapter  I,  we  stated  that  the  solution  to  the  system  required  by  the  UMD 
performer  team  in  the  short  run  stemmed  from  the  answers  to  the  following  questions: 

1.  What  are  the  requirements  for  system  to  be  implemented  by  the  NPS 
performer  team? 

2.  What  is  the  appropriate  design  of  a  modular  framework  to  effectively 
manage  the  natural  language  assertions  in  a  knowledge  base  repository 
and  the  sharing  of  the  knowledge  via  the  World  Wide  Web? 

3.  What  is  the  appropriate  Web-service  design  to  allow  for  multiple  users  to 
update  the  knowledge  base  repository  of  natural  language  assertions  from 
multiple  sites? 

To  address  these  questions,  we  began  our  research  with  an  investigation  of  SOA 
and  Web  services.  This  background  information  introduces  the  key  concepts  we 
expanded  upon  in  the  remainder  of  the  thesis. 
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Chapter  III  began  with  the  introduction  of  an  abstract  system  domain  model  that 
showed  the  components  and  their  relationships  to  one  another.  We  then  presented  the 
stakeholder-validated  software  requirements  to  answer  question  number  one.  The  SRS 
included  several  use  cases  and  SSDs  to  demonstrate  the  core  system  functionality.  This  is 
the  initial  version  of  the  requirements  specification,  and  is  subject  to  iterative 
development  based  on  the  needs  of  the  stakeholders. 

For  questions  two  and  three,  we  started  with  an  illustration  of  the  four  main  tiers 
of  the  system  architecture:  database,  business  logic,  Web,  and  the  presentation.  We  then 
delved  into  each  tier  and  discussed  its  respective  design  features.  For  the  database,  we 
presented  an  ER  diagram  and  then  followed  a  six-step  algorithm  to  nonnalize  the 
elements  into  a  relational  database  design.  The  business  logic  tier  was  addressed  by 
showing  the  particular  system  data  types  and  elements  of  the  XML  schema  to  be  used  in 
the  creation  of  our  WS  and  client,  along  with  their  respective  class  diagrams.  For  the 
Web  tier,  we  presented  elements  of  our  WSDL,  which  described  our  WS  interfaces  for 
our  future  clients.  Lastly,  using  PowerPoint,  we  prototyped  the  layout  of  the  graphical 
user  Web  interface  that  will  enable  the  local  users  to  perform  the  core  system 
functionality  including  managing  the  assertion  data  and  capability  status.  We  finished  the 
design  of  our  presentation  tier  with  the  Web  application  class  diagrams. 

The  thesis  concludes  with  a  description  of  the  SCIL  prototype  that  we 
implemented.  We  demonstrated  the  execution  of  the  system  functions  by  walking  the 
reader  through  a  scenario  that  involved  a  user  setting  the  capability  status  and  also 
performing  the  three  main  functions  of  the  KbUpdate  client. 

The  significance  of  this  research  is  that  it  will  support  the  analysis  of  the  social 
dynamics  behind  certain  groups  of  interest  by  managing  the  assertions  generated  from 
online  chat  communication.  The  prototype  will  serve  as  a  vehicle  to  elicit  additional 
requirements  for  SCIL. 

B.  FUTURE  WORK 

The  prototype  described  in  this  thesis  uses  a  relational  database  schema  to 


organize  the  system  data.  We  did  not  delve  into  the  use  of  an  object-relational  or  an 
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object-oriented  database  management  system.  Since  we  used  an  object-oriented 
programming  language  to  develop  the  system  software,  it  would  seem  to  be  more 
efficient  to  use  a  database  that  is  designed  to  store  objects  instead  of  tuples.  The  data 
types  used  in  the  prototype  where  simple  and  easy  to  implement  using  MySQL,  but  a 
RDBMS  does  not  handle  complex  data  types  as  well  as  object-relational  or  object- 
oriented  database  management  systems.  An  analysis  of  using  either  of  these  database 
management  systems  is  a  subject  of  future  research. 

The  system  design  did  not  address  concurrency  issues  that  can  be  encountered 
when,  for  example,  two  or  more  users  attempt  to  concurrently  modify  the  same  assertion. 
A  race  condition  is  a  particular  example  of  a  concurrency  issue.  Stallings  defines  a  race 
condition  as  “A  situation  in  which  multiple  threads  or  processes  read  and  write  a  shared 
data  item  and  the  final  result  depends  on  the  relative  timing  of  their  execution”  (Stallings, 
2009,  p.  207).  An  analysis  of  these  system  issues  and  their  consequences  would  help  to 
ensure  that  the  integrity  of  the  data  is  not  compromised. 

We  designed  a  Web  GUI  for  the  system,  but  this  feature  was  not  implemented  in 
our  prototype.  An  analysis  of  some  of  the  popular  Web-development  technologies  (e.g., 
Ajax  Frameworks,  Java  Server  Faces,  and  Microsoft’s  ASP.Net)  is  needed  to  identify 
which  of  these  techniques  should  be  used  to  implement  the  deployed  system. 

The  intent  behind  the  DataPush  client  mentioned  in  Chapter  III  is  still  in  debate 
amongst  the  UMD  stakeholders.  Since  the  KbUpdate  client  already  sends  assertions  to 
the  external  system,  it  would  be  redundant  to  implement  another  Web  client  alongside 
KbUpdate  to  perform  the  same  function.  We  recommend  that  the  DataPush  client  either 
be  dropped  from  further  discussion  or  clearly  specified  to  warrant  the  development  of 
another  Web  client. 
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APPENDIX.  XML  SCHEMA 


<?xml  version="1.0"  encoding="UTF-8"?> 

<!--  edited  with  XMLSpy  v2010  (http://www.altova.com)  by  Havier  Palomo  (Naval 
Postgraduate  School)  --> 

<xs : schema  xmlns : stepd="http : //www. iarpa . gov/SCIL/STEP_Schema" 

xmlns :xs=" http: //www. w3 .org/2001/XMLSchema" 

ta rget Names pace=" http: //www. iarpa . gov/SCIL/STEP_Schema" 

element FormDefau It =" qualified"  attributeFormDefault="unqualified"  version="l. 3d 
xml:lang="EN"> 

<!--  Schema  Documentation  --> 

<xs : annotation> 

<xs : documentation) 

XSD  for  STEP  (the  IARPA  SCIL  Program  SOA  Platform) 

Original  Publication  Date:  2009-10-26 
Current  Date:  2010-08-27 
Current  Version:  1.3d 
</xs  documentation) 

<xs  documentation) 

Change  Log  (from  Version  1.2) 

2010-07-14  :  Makes  claims  predicate-based;  no  wildcards 
2010-07-16  :  Enumerates  claims  by  team 

2010-07-21  :  Changes  the  claim  context  element  to  SocialConstructDomain--an 
enumerated  type 

2010-08-21  :  Adds  a  SocialConstruct  element  to  the  assertions  context--a  simple 
string 

</xs  documentation) 

</xs:annotation> 

<!--  Global  Types  used  in  defining  KB  content  --> 

<!--  Utility  Types--) 

<xs : complexType  name="DataSource" > 

<xs : annotation) 

<xs:documentation>Type  that  defines  the  data  source  used  in  generating  an 
assertion . 

</xs  documentation) 

</xs : annotation) 

<xs : sequence) 

<xs : element  name="DataMetadata") 

<xs : annotation) 

<xs : documentation>Metadata  that  describes  the  source  of  the  data. 

</xs : documentation) 

</xs:annotation> 

<xs : complexType) 

<xs : sequence) 

<xs:element  name="SourceName"  type="xs:string"> 

<xs : annotation) 

<xs:documentation)The  name  of  the  source. </xs : documentation) 

</xs:annotation> 

</xs:element> 

<xs:element  name="SourceLocation"  type="xs:anyURI"> 

<xs : annotation) 

<xs:documentation)A  URI  that  allows  the  data  to  be  located.  Can  be  a  dummy 
value . </xs : documentation) 
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</xs:annotation> 

</xs:element> 

<xs:element  name="SourceLanguage"  type="xs : language"> 

<xs : annotation> 

<xs:documentation>The  human  language  of  the  source. </xs : documentation> 
</xs:annotation> 

</xs:element> 

<xs:element  name="SourceType"  type="xs:string"> 

<xs : annotation> 

<xs:documentation>The  type  of  source:  blog,  emails  broadcast  conversation, 
etc .  </xs : documentation > 

</xs:annotation> 

</xs:element> 

<xs : element  name="SourceMedium"> 

<xs : annotation> 

<xs:documentation>A  enumerated  list.  Currently  just  text  or 
speech . </xs : document at ion > 

</xs : annotation> 

<xs : simpleType> 

<xs : restriction  base="xs : string"> 

<xs : enumeration  value="text"/> 

<xs : enumeration  value=" speech" /> 

</xs : restriction> 

</xs : simpleType> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

<xs:element  name="DataSegment"  minOccurs="0"  maxOccurs="unbounded"> 

<xs : annotation> 

<xs:documentation>A  segment  of  the  source  data  processed  in  generating  the  claim. 
</xs : document at ion > 

</xs : annotation> 

<xs : complexType> 

<xs : sequence> 

<xs: element  name="SourceDataSegment"  type="xs : string"/> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

<xs : complexType  name="KbClaim" > 

<xs : sequence> 

<xs : element  name="PredicateClaim"> 

<xs : complexType> 

<xs : sequence> 

<xs: element  name="PredicateName"  type="xs : string"  default="Persuasion  Attempt"/> 
<xs:element  name="Speaker"> 

<xs : complexType> 

<xs : sequence? 

<xs: element  name="Entity"  type="stepd : Entity"/? 

</xs : sequence? 

</xs : complexType? 

</xs:element? 

<xs:element  name="Target"? 

<xs : complexType? 

<xs : sequence? 
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<xs:element  name="Entity"  type="stepd : Entity"  maxOccurs="unbounded"/> 

</xs : sequence> 

<xs : attribute  name="type"  type="xs : string"  default="directed"> 

</xs:attribute> 

</xs : complexType> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

<xs : complexType  name="Entity"> 

<xs : sequence> 

<xs:element  name="id"  type="xs : integer"/> 

<xs:element  name="type"  type="xs : string"  default="person"> 

<xs : annotation> 

<xs:documentation>  "type"  refers  to  the  entity  being  either  a  person  or  a 
group</xs : document at ion > 

</xs : annotation> 

</xs:element> 

<xs: element  name="role"  type="xs : string"> 

<xs : annotation> 

<xs : documentation>  "role"  refers  to  the  wether  the  entity  is  either  the  speaker  or 
target</xs : documentation> 

</xs:annotation> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

<xs : complexType  name="KbEvidence" > 

<xs : sequence> 

<xs:element  name="EvidenceValue"  type="xs : string"> 

<xs : annotation> 

<xs:documentation>An  overall  assessment  of  the  degree  to  which  the  set  of  evidence 
statements  support  the  claim.  It  can  be  a  Bayesian  probability,  an  interval 
probability,  a  fuzzy  number,  a  modal,  a  value  on  a  Likert  scale,  etc.  ;  whatever 
the  underlying  theory  of  evidence  supports. 

</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs : element  name="EvidenceStatement"  type="stepd : EvidenceStatement"/> 

</xs : sequence> 

</xs : complexType> 

<xs : simpleType  name="Display"> 

<xs : restriction  base="xs : string" > 

<xs:enumeration  value="Weak  Confidence. "/> 

<xs:enumeration  value="Strong  Confidence. "/> 

<xs:enumeration  value="No  Confidence. "/> 

</xs : restriction> 

</xs : simpleType> 

<xs : complexType  name="EvidenceStatement"> 

<xs : sequence> 

<xs : element  name="ConstituentMultiset" > 

<xs : complexType> 

<xs : sequence> 

<xs:element  name="PersuasionTactic"  maxOccurs="unbounded"> 

<xs : complexType> 

<xs : group  ref="stepd : PersuasionTacticGroup"/> 
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</xs : complexType> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

<xs : group  name="PersuasionTacticGroup"> 

<xs : all> 

<xs:element  name="tactic"  type="xs : string"/> 

<xs:element  name="startline"  type="xs : integer"/> 

<xs:element  name="endline"  type="xs : integer"/> 

<xs:element  name="doc"  type="xs : string"/> 

</xs:all> 

</xs:group> 

<xs : complexType  name="KbSupport"> 

<xs : sequence> 

<xs:element  name="TheoreticalFrame"  type="xs : string"/> 

<xs:element  name="TechnicalTerm"  maxOccurs="unbounded"> 

<xs : complexType> 

<xs : sequence> 

<xs:element  name="TechnicalTermGloss"  type="xs : string"/> 

<xs:element  name="DataSnippet"  type="xs : string"/> 

</xs : sequence) 

<xs : attribute  name="term"  type="xs : string"  default="redefinition"/> 

</xs : complexType) 

</xs:element> 

</xs : sequence) 

</xs : complexType) 

<xs : complexType  name="KbAssertion" > 

<xs : sequence) 

<xs : element  name= "Assert ionMetadata") 

<xs : complexType) 

<xs : sequence) 

<xs:element  name="AssertionId"  type="xs:string"> 

<xs : annotation) 

<xs:documentation)Performer  team  generated  ID  for  this 
assertion . </xs : documentation) 

</xs:annotation> 

</xs:element> 

<xs:element  name="AssertionDtg"  type="xs :dateTime"> 

<xs : annotation) 

<xs:documentation>Performer  team  generated  DTG  on  which  this  assertion  was 
created . </xs : documentation) 

</xs : annotation) 

</xs:element> 

<xs : element  name=" Assert ion Flag"  type="stepd : Assert ion Flag") 

<xs : annotation) 

<xs : documentation>Performer  team  generated  flag  that  indicates  whether  this  is  a 
"public"  or  "private"  assertion . </xs : documentation) 

</xs:annotation> 

</xs:element> 

</xs : sequence) 

</xs : complexType) 

</xs:element> 

<xs : element  name="AssertionContext") 

<xs : complexType) 
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<xs : sequence> 

<xs:element  name="LanguageUseDomain"  type="xs : string"  default="Persuasion 
Attempt"> 

<xs : annotation> 

<xs:documentation>A  string  that  specifies  the  Language  Use  domain  that  the 
assertion  targets.  Will  ultimately  be  an  enumerated  list.</xs:documentation> 

</xs : annotation> 

</xs:element> 

<xs: element  name="DataSet"  type="stepd : DataSource"> 

<xs : annotation> 

<xs : documentation>The  data  set  from  which  the  evidence  for  the  claim  is 
drawn . </xs : documentation> 

</xs : annotation> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

<xs: element  name="AssertionClaim"  type="stepd : KbClaim"/> 

<xs : element  name="AssertionEvidence"  type="stepd : KbEvidence"/> 

<xs : element  name="AssertionSupport"  type="stepd : KbSupport"/> 

</xs : sequence> 

</xs : complexType> 

<xs : simpleType  name=" Assert ion F lag" > 

<xs : restriction  base="xs : string" > 

<xs : enumeration  value=" private"/ > 

<xs : enumeration  value=" public "/> 

</xs : restriction> 

</xs : simpleType> 

<xs : simpleType  name="ServiceState" > 

<xs : annotation> 

<xs:documentation>Type  that  defines  the  state  that  a  service  capability  can  be 
in . </xs : document at ion > 

</xs : annotation> 

<xs : restriction  base="xs : string" > 

<xs : enumeration  value="available"/> 

<xs : enumeration  value=" unavailable "/> 

<xs : enumeration  value=" unsupported "/> 

</xs : restriction> 

</xs : simpleType> 

<xs : complexType  name="ServiceStatusReport"> 

<xs : annotation) 

<xs : documentation>Type  that  defines  the  status  report  generated  by  a  Performer 
team. </xs : documentation) 

</xs:annotation> 

<xs : sequence) 

<xs : element  name="KbUpdateCapability") 

<xs : annotation) 

<xs:documentation)Status  of  the  KbUpdate  capability.  Current  state  and  DTG  of  last 
kb  update. </xs:documentation> 

</xs : annotation) 

<xs : complexType) 

<xs : sequence) 

<xs:element  name="State"  type="stepd:ServiceState"/> 

<xs:element  name="LastDtg"  type="xs:dateTime"/) 

</xs : sequence) 

</xs : complexType) 

</xs:element> 
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<xs : element  name="DataPushCapability"> 

<xs : annotation> 

<xs:documentation>Status  of  the  DataPush  capability.  Current  state  and  DTG  of  last 
data  push.</xs:documentation> 

</xs : annotation> 

<xs : complexType> 

<xs : sequence> 

<xs:element  name="State"  type="stepd:ServiceState"/> 

<xs:element  name="LastDtg"  type="xs:dateTime"/> 

</xs : sequence) 

</xs : complexType) 

</xs:element> 

<xs : element  name="ExplanationGetCapability"> 

<xs : annotation) 

<xs : documentation)Status  of  the  ExplanationGet  capability.  Current  state  and  DTG 
of  last  explanation  returned . </xs : documentation) 

</xs : annotation) 

<xs : complexType) 

<xs : sequence) 

<xs:element  name="State"  type="stepd:ServiceState"/) 

<xs:element  name="LastDtg"  type="xs:dateTime"/> 

</xs : sequence) 

</xs : complexType) 

</xs:element> 

</xs : sequence) 

</xs : complexType) 

<xs : complexType  name=" St at us Request Bundle") 

<xs : annotation) 

<xs:documentation)Type  that  defines  a  STEP  server  request  for  a  status  check. 
Currently  not  used.</xs:documentation> 

</xs : annotation) 

</xs : complexType) 

<xs : complexType  name="StatusReturnBundle") 

<xs : annotation) 

<xs : documentation)Type  that  defines  the  Performer  team  response  to  a  status  check 
request. </xs :documentation> 

</xs : annotation) 

<xs : sequence) 

<xs:element  name="Payload"> 

<xs : complexType) 

<xs : sequence) 

<xs : element  name="StatusReport"  type="stepd : ServiceStatusReport"/) 

</xs : sequence) 

</xs : complexType) 

</xs:element> 

</xs : sequence) 

</xs : complexType) 

<xs : complexType  name=" Explanation Request Bundle") 

<xs : annotation) 

<xs:documentation)Type  that  defines  a  STEP  server  request  for  an  explanation. 
Currently  minimally  specified . </xs : documentation) 

</xs : annotation) 

<xs : sequence) 

<xs: element  name="Metadata"> 

<xs : complexType) 

<xs : sequence) 

<xs:element  name="AssertionId"  type="xs:string"> 
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<xs :  annotation 

<xs:documentation>STEP  ID  of  the  assertion  for  which  an  explanation  is 
requested . </xs : documentation> 

</xs:annotation> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

<xs : complexType  name="ExplanationReturnBundle"> 

<xs : annotation> 

<xs:documentation>Type  that  defines  the  Performer  team  response  to  an  explanation 
request.  Currently  a  placeholder. </xs:documentation> 

</xs : annotation> 

<xs : sequence> 

<xs: element  name="Metadata"> 

<xs : complexType> 

<xs : sequence> 

<xs: element  name="AssertionId"  type="xs : string"> 

<xs : annotation> 

<xs : documentation>STEP  ID  of  the  assertion  that  this  explanation  refers 
to. </xs : document at ion > 

</xs:annotation> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

<xs:element  name="Payload"> 

<xs : complexType> 

<xs : sequence> 

<xs:element  name="Assertion"  type="stepd : KbAssertion"  maxOccurs="unbounded"/> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

<xs : element  name="StatusReportRequestMsgPart"> 

<xs : annotation> 

<xs:documentation>Used  in  a  message  sent  by  the  STEP  server  to  request  a  Performer 
team  capability  status  check. </xs :documentation> 

</xs : annotation> 

<xs : complexType> 

<xs : sequence> 

<xs:element  name="Metadata"> 

<xs : complexType> 

<xs : sequence> 

<xs: element  name="MessageId"  type="xs : string"> 

<xs : annotation> 

<xs:documentation>Message  ID  generated  by  the  STEP  server. </xs:documentation> 
</xs:annotation> 

</xs:element> 

<xs:element  name="RequestorId"  type="xs:string"> 

<xs : annotation> 

<xs:documentation>ID  of  the  requestor  (typically  the  STEP  server)  of  the  status 
report . </xs : documentation> 

</xs:annotation> 
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</xs:element> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

<xs : element  name="StatusReportResponseMsgPart"> 

<xs : annotation> 

<xs:documentation>Used  in  a  message  sent  by  a  Performer  team  in  response  to  a 
StatusReport  request . </xs : documentation> 

</xs : annotation> 

<xs : complexType> 

<xs : sequence> 

<xs: element  name="Metadata"> 

<xs : complexType> 

<xs : sequence> 

<xs: element  name="MessageId"  type="xs : string"> 

<xs : annotation> 

<xs : documentation>ID  of  the  status  request  message  to  which  this  message  is  a 
response . </xs : documentation> 

</xs : annotation> 

</xs : element> 

<xs:element  name="RequestorId"  type="xs:string"> 

<xs : annotation> 

<xs:documentation>ID  of  the  ultimate  requestor  of  the  status  check.  Typically  the 
STEP  server. </xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

<xs:element  name="Payload"> 

<xs : complexType> 

<xs : sequence> 

<xs : element  name="StatusReturnBundle"  type="stepd : StatusReturnBundle"/> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

<xs : element  name="ExplanationGetRequestMsgPart"> 

<xs : annotation> 

<xs:documentation>Used  in  a  message  sent  by  the  STEP  server  to  request  an 
explanation  for  an  assertion. </xs:documentation> 

</xs:annotation> 

<xs : complexType> 

<xs : sequence> 

<xs:element  name="Metadata"> 

<xs : complexType> 

<xs : sequence> 

<xs:element  name="MessageId"  type="xs : string"> 

<xs : annotation> 

<xs:documentation>Message  ID  generated  by  the  STEP  server. </xs :documentation> 
</xs:annotation> 

</xs:element> 
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<xs:element  name="RequestorId"  type="xs:string"> 

<xs :  annotation 

<xs:documentation>ID  of  the  requestor  (typically  a  user)  of  the 
explanation . </xs : documentation> 

</xs:annotation> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

<xs:element  name="Payload"> 

<xs : complexType> 

<xs : sequence> 

<xs : element  name=" Explanation Request Bundle" 
type="stepd : ExplanationRequestBundle"/> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

</xs : sequence> 

</xs : complexType> 

</xs:element> 

<xs : element  name="ExplanationGetResponseMsgPart"> 

<xs : annotation> 

<xs:documentation>Used  in  a  message  sent  by  a  Performer  team  in  response  to  an 
ExplantionGet  request . </xs : documentation > 

</xs : annotation> 

<xs : complexType> 

<xs : sequence> 

<xs:element  name="Metadata"> 

<xs : complexType> 

<xs : sequence> 

<xs:element  name="MessageId"  type="xs : string"> 

<xs : annotation> 

<xs:documentation>ID  of  the  explanation  request  message  to  which  this  message  is  a 
response. </xs : document at ion > 

</xs : annotation> 

</xs:element> 

<xs:element  name="RequestorId"  type="xs:string"> 

<xs : annotation> 

<xs : documentation>ID  of  the  ultimate  requestor  of  the  explanation.  Typically  an 
end-user .</xs: document at ion > 

</xs : annotation> 

</xs:element> 

</xs : sequence) 

</xs : complexType) 

</xs:element> 

<xs:element  name="Payload"> 

<xs : complexType) 

<xs : sequence) 

<xs : element  name=" Explanation Ret urnBundle"  type="stepd : ExplanationReturnBundle"/) 
</xs : sequence) 

</xs : complexType) 

</xs : element) 

</xs : sequence) 

</xs : complexType) 

</xs : element) 

</xs : schema) 
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